> On 3 May 2019, at 20:13, Toke Høiland-Jørgensen <[email protected]> wrote: > > Kevin Darbyshire-Bryant <[email protected]> writes: > >>> On 3 May 2019, at 15:16, Jonathan Morton <[email protected]> wrote: >>> >>>> On 3 May, 2019, at 4:55 pm, Kevin Darbyshire-Bryant >>>> <[email protected]> wrote: >>>> >>>> Two patches attached - one is a simple variable elimination with no >>>> functional change. The second changes/simplifies the conntrack tuple >>>> lookup & usage. I’ve had a play and I don’t think I’ve broken any of the >>>> host fairness BUT it could do with some more testing, that’s where you >>>> come in… >>> >>> Looks like sound logic, as long as it does actually work. It could be a >>> useful speedup for those small CPE devices which need NAT and host-fairness >>> working. >> >> It’s interesting you bring that up - are we sure that ingress host NAT >> fairness works in the upstream kernel version of CAKE anyway? I’m >> looking at cake_update_flowkeys(…) and thinking half of it is missing? > > No, it's just moved into nf_conntrack_get_tuple_skb(); this was part of > the work we did to ensure sch_cake could load without a dependency on > the conntrack module... > > It does carry over the 'nf_ct_tuple(ct, !hash->tuple.dst.dir);' and the > subsequent reversion, though, but I think the logic fits what's in the > out-of-tree version? > > -Toke
Ahh! yes I see, thanks. - elixir or my ability to operate elixir was failing earlier. Yes and agree the logic follows the out-of-tree…and I can see how my change to it would be applied, assuming it does actually work. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
