[Cake] Possible conntrack lookup improvements
kevin at darbyshire-bryant.me.uk
Fri May 3 19:57:44 EDT 2019
> On 3 May 2019, at 20:23, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
>> On 3 May 2019, at 20:13, Toke Høiland-Jørgensen <toke at redhat.com> wrote:
>> Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> writes:
>>>> On 3 May 2019, at 15:16, Jonathan Morton <chromatix99 at gmail.com> wrote:
>>>>> On 3 May, 2019, at 4:55 pm, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> 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?
> 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.
gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
More information about the Cake