On Fri, 24 Sept 2021 at 20:38, Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > > > 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
