Re: Expose skb_gso_validate_network_len() [Was: ebtables: load-on-demand extensions]

[Eugene Crosser <crosser@average.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1770 bytes --]

On 21/06/2020 12:03, Jan Engelhardt wrote:

>>>> No, nft already has "< $value" logic.
>>>> The only missing piece of the puzzle is a way to populate an nft
>>>> register with the "size per segment" value.
>>>
>>> I don't think that it works. `skb_gso_network_seglen()` gives the (same for all
>>> segments) segment length _only_ when `shinfo->gso_size != GSO_BY_FRAGS`. If we
>>> were to expose maximum segment length for skbs with `gso_size == GSO_BY_FRAGS`,
>>> we'd need a new function that basically replicates the functionality of
>>> `skb_gso_size_check()` and performs `skb_walk_frags()`, only instead of
>>> returning `false` on first violation finds and then returns the maximum
>>> encoutered value.
>>
>> Yes.
>>
>>> That means we'd need to introduce a new function for the sole purpose of making
>>> the proposed check fit in the "less-equal-greater" model.
>>
>> Yes and no.
>>
>>> And the only practical
>>> use of the feature is to check "fits-doesn't fit" anyway.
>>
>> Why?  Maybe someone wants to collect statistics on encountered packet
>> size or something like that.
> 
> Possibly so, but you would not want to penalize users who do
> want the short-circuiting behavior when they are not interested
> in the statistics.

In my opinion, for what it's worth, performance pentalty will likely be
insignificant, and in most cases (`shinfo->gso_size != GSO_BY_FRAGS`) non-existent.

But the thing that makes me feel rather uneasy about the "expose the value" plan
is that the kernel will get two distinct, very similar in their workflow, but
slightly different functions. Next time someone wants to change GSO processing
they will need to take care of both places.

So, which way to go?..

Regards,

Eugene


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]