On Sun, 2016-01-31 at 05:36 -0500, Tejun Heo wrote: > Hello, > > On Sat, Jan 30, 2016 at 10:03:58AM +0100, James Bottomley wrote: > > Probably out of scope for LSF/MM but this does beg the question of > > why > > traffic control in block is done by a cgroup but not in net ... I > > think > > the answer is "historical reasons", but if the net traffic > > classifiers > > at least were cgroups, we might get more sharing between net and > > block > > traffic control. > > Network was dynamic and configurable way before cgroup came along and > thus has its own naming, classification and control schemems, so it > makes sense for cgroup to just hook into the existing facilities. > So, > it's partially historical but that's not the whole story. Yes, but I concede the history point: rewriting just because we did it a different way a while ago and would do it differently today isn't necessarily a good idea. > cgroup membership is but a tiny portion of how network traffic is > shaped and routed - e.g. the destination address, port or packet type > are factors too. cgroup can't slurp in all those. It has to be one > part of the pieces that the networking stack considers. Yes and no. In the old days, when I set up ingress and egress traffic control, I did use the TC filters to properly classify my flows. However, when I recently redid this, I dumped all the tc filter code in favour of classifying from firewall rules. I'm not necessarily saying this is what everyone should do, but it does show that the job of classifying the packets can be completely separated from the job of applying the controls to the classes. James -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
