Re: Redux: Backwards compatibility for XDP multi-buff

[Lorenz Bauer <lmb@cloudflare.com>]

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