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

[Florian Westphal <fw@strlen.de>]

Eugene Crosser <crosser@average.org> 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.

(Yes, they could also use tcpdump of course).

Or maybe someone wants to do QoS markings on packet sizes, so tehy could
have a map like

{ 0 - 64 : 0x1, 65-1280 : 0x2, 1281-1400 : 0x3 } or whatever.

Point is that nft tries to provide only basic building blocks and allow
users to plumb this together.

> Do you think this is a valid argument to implement a boolean predicate rather
> than expose an arithmetic value?

I would rather see an arithmetic value.

GSO_BY_FRAGS should not occur in forwarding path nornally, but I guess
it might show up with veth coming from a VM, and I indeed forgot about it.