> On 3 May 2019, at 20:23, Kevin Darbyshire-Bryant > <[email protected]> wrote: > > > >> 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. >
My testing strategy was flawed, the 2nd patch does not work correctly. Will think again. > 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
