[Cake] fq_codel leveraging the skb->hash now in net-next

[Cake] fq_codel leveraging the skb->hash now in net-next

[Dave Taht]

It's not clear to me if all the encapsulation types (6rd for
example?), or drivers? are generating an skb->hash (or as of what
release of linux they did), and there's no error checking for 0, and
whether or not they are being permuted in skb->hash,  (otherwise all
linux implementations in the world will end up hashing the same way on
the same combination of ips and ports),

but I tend to trust eric to get it right, and hashing here was always
the 2nd or 3rd biggest hotspot in fq_codel.

https://www.mail-archive.com/netdev@vger.kernel.org/msg148598.html

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cake] fq_codel leveraging the skb->hash now in net-next

[Eric Dumazet]

The 0 case is checked.

If skb->hash == 0 or a non L4 hash was stored in skb->hash, we call
the same flow dissector code than before ;)

And each host has normally :

1) Boot time generated RSS keys on NIC providing skb->hash
2) A boot time random number
static u32 hashrnd __read_mostly;
static __always_inline void __flow_hash_secret_init(void)
{
        net_get_random_once(&hashrnd, sizeof(hashrnd));
}

u32 flow_hash_from_keys(struct flow_keys *keys)
{
        __flow_hash_secret_init();
        return __flow_hash_from_keys(keys, hashrnd);
}
EXPORT_SYMBOL(flow_hash_from_keys);

static inline u32 ___skb_get_hash(const struct sk_buff *skb,
                                  struct flow_keys *keys, u32 keyval)
{
        skb_flow_dissect_flow_keys(skb, keys,
                                   FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL);

        return __flow_hash_from_keys(keys, keyval);
}


So an attacker has no way to guess in which slot of the hash table a
particular flow will end up.


For the record, I will add (optional) pacing to fq_codel.

On Fri, Jan 20, 2017 at 1:29 PM, Dave Taht <dave.taht@gmail.com> wrote:
> It's not clear to me if all the encapsulation types (6rd for
> example?), or drivers? are generating an skb->hash (or as of what
> release of linux they did), and there's no error checking for 0, and
> whether or not they are being permuted in skb->hash,  (otherwise all
> linux implementations in the world will end up hashing the same way on
> the same combination of ips and ports),
>
> but I tend to trust eric to get it right, and hashing here was always
> the 2nd or 3rd biggest hotspot in fq_codel.
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg148598.html
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org

Re: [Cake] fq_codel leveraging the skb->hash now in net-next

[Dave Taht]

On Fri, Jan 20, 2017 at 1:36 PM, Eric Dumazet <edumazet@google.com> wrote:
> The 0 case is checked.
>
> If skb->hash == 0 or a non L4 hash was stored in skb->hash, we call
> the same flow dissector code than before ;)
>
> And each host has normally :
>
> 1) Boot time generated RSS keys on NIC providing skb->hash
> 2) A boot time random number
> static u32 hashrnd __read_mostly;
> static __always_inline void __flow_hash_secret_init(void)
> {
>         net_get_random_once(&hashrnd, sizeof(hashrnd));
> }
>
> u32 flow_hash_from_keys(struct flow_keys *keys)
> {
>         __flow_hash_secret_init();
>         return __flow_hash_from_keys(keys, hashrnd);
> }
> EXPORT_SYMBOL(flow_hash_from_keys);
>
> static inline u32 ___skb_get_hash(const struct sk_buff *skb,
>                                   struct flow_keys *keys, u32 keyval)
> {
>         skb_flow_dissect_flow_keys(skb, keys,
>                                    FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL);
>
>         return __flow_hash_from_keys(keys, keyval);
> }
>
>
> So an attacker has no way to guess in which slot of the hash table a
> particular flow will end up.

Groovy. safe to backport to 4.4? (lede/openwrt)?

> For the record, I will add (optional) pacing to fq_codel.

BBR is one less step away from world domination then!

My dream has always been to have all timestamping being on ingress,
thus eliminating that within fq_codel also, thus measuring cpu
overload on queuing within linux itself. This would also tend toward
favoring local tcp flows (I think), slightly, in the fq_codel case.

But perhaps I'm still dreaming too hard.

>
> On Fri, Jan 20, 2017 at 1:29 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> It's not clear to me if all the encapsulation types (6rd for
>> example?), or drivers? are generating an skb->hash (or as of what
>> release of linux they did), and there's no error checking for 0, and
>> whether or not they are being permuted in skb->hash,  (otherwise all
>> linux implementations in the world will end up hashing the same way on
>> the same combination of ips and ports),
>>
>> but I tend to trust eric to get it right, and hashing here was always
>> the 2nd or 3rd biggest hotspot in fq_codel.
>>
>> https://www.mail-archive.com/netdev@vger.kernel.org/msg148598.html
>>
>> --
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> http://blog.cerowrt.org



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org