<div dir="ltr">Ah, so it DOES support multiple flow hashes... I didn't know that.  Nice.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 21, 2014 at 1:31 AM, Eric Dumazet <span dir="ltr"><<a href="mailto:eric.dumazet@gmail.com" target="_blank">eric.dumazet@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On Tue, 2014-05-20 at 20:16 +1000, Andrew McGregor wrote:<br>
> That's about what constitutes a flow.  fq_codel as implemented in<br>
> linux works per (source ip, dest ip, protocol, source port, dest port)<br>
> 5-tuple.  Linux should probably support multiple flow hashing<br>
> algorithms in the kernel.<br>
><br>
<br>
</div>Right. fq_codel uses the same trick than other qdisc, like SFQ<br>
<br>
By _default_ it uses a 5-tuple hash. Thats convenient but not a<br>
requirement.<br>
<br>
You can classify packets using a filter and for example hash only on the<br>
part you need. For example destination IP, or source IP, depending if<br>
you use fq_codel on egress or ingress sides.<br>
<br>
tc qdisc add dev eth0 root handle 1: fq_codel flows 8192<br>
tc filter add dev eth0 protocol ip parent 1: handle 1 \<br>
        flow hash keys dst divisor 8192<br>
<br>
Simple as that.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Tue, May 20, 2014 at 7:15 PM, Richard Edmands <<a href="mailto:thesirdmz@gmail.com">thesirdmz@gmail.com</a>><br>
> wrote:<br>
>         In my environment we've got a fair chunk of torrent usage<br>
>         happening (+ gaming) and with fq_codel giving the advantage to<br>
>         whichever individual could open up as many connections as<br>
>         possible the entire situation imploded very quickly.<br>
><br>
>         So to balance this out I used htb to implement the IP part of<br>
>         this (actually not really, i made groups of ip's which<br>
>         belonged to individuals) and stuck fq_codel on top of the<br>
>         divided setup.<br>
><br>
>         With this system what now happens is each IP now gets equal<br>
>         utilization of the link (actually, i'm a lazy hack. I only<br>
>         implemented the uplink section) which prevents the advantage<br>
>         of opening up as many connections as possible.<br>
>         Now when an individual decides to go nuts, they're limited to<br>
>         what is available to them without harming everyone else,<br>
>         without compromising maximum possible speed.<br>
><br>
><br>
>         I have had this running in my environment for the past month<br>
>         and WOW.<br>
><br>
><br>
>         See pastebin'd implementation.<br>
><br>
><br>
>         <a href="http://pastebin.com/hXtzFL9f" target="_blank">http://pastebin.com/hXtzFL9f</a><br>
><br>
><br>
>         _______________________________________________<br>
>         Codel mailing list<br>
>         <a href="mailto:Codel@lists.bufferbloat.net">Codel@lists.bufferbloat.net</a><br>
>         <a href="https://lists.bufferbloat.net/listinfo/codel" target="_blank">https://lists.bufferbloat.net/listinfo/codel</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Codel mailing list<br>
> <a href="mailto:Codel@lists.bufferbloat.net">Codel@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/codel" target="_blank">https://lists.bufferbloat.net/listinfo/codel</a><br>
<br>
<br>
</div></div></blockquote></div><br></div>