Re: [PATCH] flow_dissector: introduce skb_get_hash_symmetric()

[Jon Kohler]

> On May 31, 2023, at 1:33 PM, Eric Dumazet <edumazet@xxxxxxxxxx> wrote:
> 
> On Wed, May 31, 2023 at 7:22 PM Jon Kohler <jon@xxxxxxxxxxx> wrote:
>> 
>> tun.c changed from skb_get_hash() to __skb_get_hash_symmetric() on
>> commit feec084a7cf4 ("tun: use symmetric hash"), which exposes an
>> overhead for OVS datapath, where ovs_dp_process_packet() has to
>> calculate the hash again because __skb_get_hash_symmetric() does not
>> retain the hash that it calculates.
>> 
>> Introduce skb_get_hash_symmetric(), which will get and save the hash
>> in one go, so that calcuation work does not go to waste, and plumb it
>> into tun.c.
>> 
>> Fixes: feec084a7cf4 ("tun: use symmetric hash")
> 
> 
>> Signed-off-by: Jon Kohler <jon@xxxxxxxxxxx>
>> CC: Jason Wang <jasowang@xxxxxxxxxx>
>> CC: David S. Miller <davem@xxxxxxxxxxxxx>
>> ---
>> 
> 
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 0b40417457cd..8112b1ab5735 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -1474,6 +1474,7 @@ __skb_set_sw_hash(struct sk_buff *skb, __u32 hash, bool is_l4)
>> 
>> void __skb_get_hash(struct sk_buff *skb);
>> u32 __skb_get_hash_symmetric(const struct sk_buff *skb);
>> +u32 skb_get_hash_symmetric(struct sk_buff *skb);
>> u32 skb_get_poff(const struct sk_buff *skb);
>> u32 __skb_get_poff(const struct sk_buff *skb, const void *data,
>>                   const struct flow_keys_basic *keys, int hlen);
>> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>> index 25fb0bbc310f..d8c0e804bbfe 100644
>> --- a/net/core/flow_dissector.c
>> +++ b/net/core/flow_dissector.c
>> @@ -1747,6 +1747,35 @@ u32 __skb_get_hash_symmetric(const struct sk_buff *skb)
>> }
>> EXPORT_SYMBOL_GPL(__skb_get_hash_symmetric);
>> 
>> +/**
>> + * skb_get_hash_symmetric: calculate and set a flow hash in @skb, using
>> + * flow_keys_dissector_symmetric.
>> + * @skb: sk_buff to calculate flow hash from
>> + *
>> + * This function is similar to __skb_get_hash_symmetric except that it
>> + * retains the hash within the skb, such that it can be reused without
>> + * being recalculated later.
>> + */
>> +u32 skb_get_hash_symmetric(struct sk_buff *skb)
>> +{
>> +       struct flow_keys keys;
>> +       u32 hash;
>> +
>> +       __flow_hash_secret_init();
>> +
>> +       memset(&keys, 0, sizeof(keys));
>> +       __skb_flow_dissect(NULL, skb, &flow_keys_dissector_symmetric,
>> +                          &keys, NULL, 0, 0, 0,
>> +                          FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL);
>> +
>> +       hash = __flow_hash_from_keys(&keys, &hashrnd);
>> +
>> +       __skb_set_sw_hash(skb, hash, flow_keys_have_l4(&keys));
>> +
>> +       return hash;
>> +}
>> +EXPORT_SYMBOL_GPL(skb_get_hash_symmetric);
>> +
> 
> Why copy/pasting __skb_get_hash_symmetric() ?
> 
> Can you reuse it ?

Not directly, because to use __skb_set_sw_hash requires struct flow_keys
when using flow_keys_have_l4(). __skb_get_hash_symmetric() does not 
take or return that struct, so we’d either have to refactor that (and its callers)
or introduce yet another function and consolidate down to that “new one”.

I played around with that exact thought by taking the functional guts out of
__skb_get_hash_symmetric, making it a new static function, plumbing that
into __skb_get_hash_symmetric and this new skb_get_hash_symmetric, but
the LOC churn was basically the same and it felt a bit worse than just a 
copy/paste.

Alternatively, if it turned out that flow_keys_have_l4() wasn’t important, we
Could simply set that to false and then reuse __skb_get_hash_symmetric
in a trivial manner. I couldn’t quite figure out if L4 flag was necessary, so I
went the safe(maybe?) route and copy/paste instead.

Happy to take suggestions either way!