Re: [Cake] Possible conntrack lookup improvements

[Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>]

> On 3 May 2019, at 20:23, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
> 
> 
> 
>> On 3 May 2019, at 20:13, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> 
>> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>> 
>>>> On 3 May 2019, at 15:16, Jonathan Morton <chromatix99@gmail.com> wrote:
>>>> 
>>>>> On 3 May, 2019, at 4:55 pm, Kevin Darbyshire-Bryant <kevin@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.
> 

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