> On March 5, 2015, 1:36 a.m., Chi Zhang wrote:
> > src/slave/containerizer/isolators/network/port_mapping.cpp, line 1531
> > <https://reviews.apache.org/r/31505/diff/2/?file=884517#file884517line1531>
> >
> > looks like the library code uses uint32_t here but your set is
> > uint16_t. assuming you have a reason to do that in the library, maybe just
> > uint32_t in the client code as well? are there other caveats?
> >
> > it's weired for the library to support a 32bit type but the client
> > takes the liberty to use a 16bit type.
It is not weird at all if you understand how a flowid is interpreted by kernel.
We only need to generate its secondary part, because its primary part is
ignored by fq_codel, we simply fill it with its parent (fq_codel::HANDLE).
if (TC_H_MIN(res.classid) <= q->flows_cnt)
return TC_H_MIN(res.classid);
As I said in comment, we do need a better API here, which is another topic.
- Cong
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31505/#review75271
-----------------------------------------------------------
On March 4, 2015, 8:18 p.m., Cong Wang wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31505/
> -----------------------------------------------------------
>
> (Updated March 4, 2015, 8:18 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/slave/containerizer/isolators/network/port_mapping.hpp 8443097
> src/slave/containerizer/isolators/network/port_mapping.cpp 5227987
>
> Diff: https://reviews.apache.org/r/31505/diff/
>
>
> Testing
> -------
>
> Manually start two mesos containers with netperf running side.
>
>
> Thanks,
>
> Cong Wang
>
>
