Re: Redux: Backwards compatibility for XDP multi-buff

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Lorenz Bauer <lmb@cloudflare.com> writes:

> On Thu, 23 Sept 2021 at 13:59, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> I don't think it has to be quite that bleak :)
>>
>> Specifically, there is no reason to block mb-aware programs from loading
>> even when the multi-buffer mode is disabled. So a migration plan would
>> look something like:
>
> ...
>
>> 2. Start porting all your XDP programs to make them mb-aware, and switch
>>    their program type as you do. In many cases this is just a matter of
>>    checking that the programs don't care about packet length. [...]
>
> 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?

-Toke