Lorenz Bauer <lmb@xxxxxxxxxxxxxx> writes: > On Thu, 23 Sept 2021 at 13:59, Toke Høiland-Jørgensen <toke@xxxxxxxxxx> 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
