-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31505/
-----------------------------------------------------------
(Updated May 12, 2015, 12:14 a.m.)
Review request for mesos, Chi Zhang, Ian Downes, and Jie Yu.
Changes
-------
Move to new API's
Bugs: MESOS-2422
https://issues.apache.org/jira/browse/MESOS-2422
Repository: mesos
Description
-------
Currently we do nothing on the host egress side. By default, kernel uses its
own hash function to classify the packets to different TX queues (if the
hardware interface supports multiqueue). So packets coming out of different
containers could end up queueing in the same TX queue, in this case we saw
buffer bloat on some TX queue caused packet drops.
We need to isolation the egress traffic so that containers will not have
interference with each other. The number of hardware TX queues is limited by
hardware interface, usually not enough to map our container in 1:1 way,
therefore we need some software solution. We choose fq_codel and use tc filters
to classify packets coming out of different containers to different fq_codel
flows, and the codel algorithm on each flow could also help us to reduce the
buffer bloat. Note when the packets leave fq_codel, they still share the
physical TX queue(s), this is however (almost) beyond what we can control, we
have to rely on the kernel behavior.
TODO: get some performance numbers
Diffs (updated)
-----
src/slave/containerizer/isolators/network/port_mapping.hpp
c72fb47f60f40cda8d84a10497b9133f83cf018e
src/slave/containerizer/isolators/network/port_mapping.cpp
a4abaff30bb4646b1b1edfdbbc243c9e3f6851df
Diff: https://reviews.apache.org/r/31505/diff/
Testing
-------
Manually start two mesos containers with netperf running side.
Thanks,
Cong Wang
