Re: [Cake] flow dissector idea/enhancement - help

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

On 01/07/16 09:11, Kevin Darbyshire-Bryant wrote:
>
>
>> I'm beginning to think there's a reason why enhanced sfq which is 
>> where I found that code never made it upstream :-/   It's been/being 
>> an interesting little diversion...and I've modified a kernel module 
>> that so far doesn't crash :-)
>>
>> KDB
> The brain cell awoke with the thought that 'we don't need all the 
> conntrack info filled in, all we need is to find the conntrack entry 
> matching the src/dst tuple depending on direction. nf_ct_get(skb, 
> &ctinfo) is a function of convenience....we need to do it the 
> inconvenient way.  there's gotta be conntrack tuple lookups available 
> and we must have enough info for this as the skb is right there.  KDB 
> goes digging.
>
> KDB

If I'm honest I'm getting a little despondent.  Coding right at the 
limit of your understand of C and the kernel and everything else is 
really, really tiring and hard.

I discovered net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c has static int
getorigdst(struct sock *sk, int optval, void __user *user, int *len)  
The comment above it is

/* Fast function for those who don't want to parse /proc (and I don't
    blame them). */
/* Reversing the socket's dst/src point of view gives us the reply
    mapping. */

Those interested to see how bad my C really is can 
https://github.com/kdarbyshirebryant/sch_cake/tree/demasq

Maybe those who know what they're doing can offer some assistance.

Cheers,

Kevin

> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake