On Fri, 24 Sept 2021 at 20:38, Toke Høiland-Jørgensen [off-list ref] wrote:

quoted

Porting is only easy if we are guaranteed that the first PAGE_SIZE
bytes (or whatever the current limit is) are available via ->data
without trickery. Otherwise we have to convert all direct packet
access to the new API, whatever that ends up being. It seemed to me
like you were saying there is no such guarantee, and it could be
driver dependent, which is the worst possible outcome imo. This is the
status quo for TC classifiers, which is a great source of hard to
diagnose bugs.

Well, for the changes we're proposing now it will certainly be the case
that the first PAGE_SIZE will always be present. But once we have the
capability, I would expect people would want to do more with it, so we
can't really guarantee this in the future. We could require that any
other use be opt-in at the driver level, I suppose, but not sure if that
would be enough?

I'm not sure what you mean by "opt-in at driver level"? Make smaller
initial fragments a feature on the driver? We shouldn't let drivers
dictate the semantics of a program type, it defeats the purpose of the
context abstraction. We're using XDP precisely because we don't want
to deal with vendor specific network stack bypass, etc. I would prefer
not specifying the first fragment size over the driver knob,
unfortunately it invalidates your assumption that porting is going to
be trivial.

Lorenz

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com