[Cake] Possible conntrack lookup improvements

[Kevin Darbyshire-Bryant]

> 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?
> 
> -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