[Cake] Possible conntrack lookup improvements
kevin at darbyshire-bryant.me.uk
Fri May 3 15:23:17 EDT 2019
> 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.
gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
More information about the Cake