> On June 2, 2015, 12:57 a.m., Chi Zhang wrote:
> > Cong, is this the patch the requires code from 3.2.26 for the first time? 
> > If so, should we add a compile-time flag to config.ac? That way Paul can 
> > safely back off the code for the "stat string conversion" from the other 
> > patch you commented on.
> 
> Cong Wang wrote:
>     No, https://reviews.apache.org/r/31503/ this one should be the first 
> commit requires 3.2.26.
> 
> Chi Zhang wrote:
>     hmm looks like both are committed? could you submit a fix for that please?

Done: https://issues.apache.org/jira/browse/MESOS-2803 . Feel free to take it 
if you have time.


- Cong


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31505/#review86133
-----------------------------------------------------------


On June 1, 2015, 10:45 p.m., Cong Wang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31505/
> -----------------------------------------------------------
> 
> (Updated June 1, 2015, 10:45 p.m.)
> 
> 
> Review request for mesos, Chi Zhang, Ian Downes, and Jie Yu.
> 
> 
> 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
> -----
> 
>   src/linux/routing/filter/basic.cpp 4ce8acb7040f2ed8ec3834dd7702a20f5316c20f 
>   src/linux/routing/filter/filter.hpp 
> aaca57fbe80e3ffa3dd2c2bbed93849013b7a382 
>   src/linux/routing/filter/icmp.cpp 76877fb94a1c1e79133b8975419d2ea7d0300650 
>   src/linux/routing/filter/ip.hpp 9645f9488938c55fec253b36d9fa30eae72a8ca2 
>   src/linux/routing/filter/ip.cpp 0f3b856bd04f6a881e35452a24399715cd8a174f 
>   src/slave/containerizer/isolators/network/port_mapping.hpp 
> 6579286b779882bec493a8e0f10486adc316dc6e 
>   src/slave/containerizer/isolators/network/port_mapping.cpp 
> 843e52d6f9923d0ee0a0297cd5c464b8b72f5de3 
> 
> Diff: https://reviews.apache.org/r/31505/diff/
> 
> 
> Testing
> -------
> 
> Manually start two mesos containers with netperf running side.
> 
> 
> Thanks,
> 
> Cong Wang
> 
>

Reply via email to