----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31505/#review74396 -----------------------------------------------------------
add a jira reference and any dependencies please. src/slave/containerizer/isolators/network/port_mapping.cpp <https://reviews.apache.org/r/31505/#comment120970> is there no better way to do this than loop over the entire set and check the hashmap? Maybe maintain a list of free flowids and take the first from the list each time. when one is freed up, add it to the back of the list. that should be O(1). src/slave/containerizer/isolators/network/port_mapping.cpp <https://reviews.apache.org/r/31505/#comment120969> This should be a Try and should return an Error if one wasn't found. src/slave/containerizer/isolators/network/port_mapping.cpp <https://reviews.apache.org/r/31505/#comment120971> check for error when getNextFlowId returns a Try src/slave/containerizer/isolators/network/port_mapping.cpp <https://reviews.apache.org/r/31505/#comment120975> any tests for this? src/slave/containerizer/isolators/network/port_mapping.cpp <https://reviews.apache.org/r/31505/#comment120972> this three lines is repeated often. maybe the 'getNextFlowId' can be changed to take the containerId and add to the mapping? src/slave/containerizer/isolators/network/port_mapping.cpp <https://reviews.apache.org/r/31505/#comment120973> metric for tracking removal errors? src/slave/containerizer/isolators/network/port_mapping.cpp <https://reviews.apache.org/r/31505/#comment120974> spaces at the front of comments please. - Dominic Hamon On Feb. 26, 2015, 3:15 p.m., Cong Wang wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/31505/ > ----------------------------------------------------------- > > (Updated Feb. 26, 2015, 3:15 p.m.) > > > Review request for mesos, Chi Zhang, Ian Downes, and Jie Yu. > > > 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 > ----- > > src/slave/containerizer/isolators/network/port_mapping.hpp > 8443097b2c79fef5ae0e23a3fb815ffec0318a93 > src/slave/containerizer/isolators/network/port_mapping.cpp > 5227987cdb7b904c2f4bb2bdf5c5d705a435010d > > Diff: https://reviews.apache.org/r/31505/diff/ > > > Testing > ------- > > Manually start two mesos containers with netperf running side. > > > Thanks, > > Cong Wang > >
