# Re: Redux: Backwards compatibility for XDP multi-buff

- From: Toke Høiland-Jørgensen \<hidden\>
- Date: 2021-09-22 20:01:46 
- List: netdev
- Page: https://ratatoskr.run/netdev/2021/09/7779950
- Thread: https://ratatoskr.run/netdev/2021/09/7779853/t.md

```text
Jakub Kicinski [ref] writes:

> On Wed, 22 Sep 2021 00:20:19 +0200 Toke Høiland-Jørgensen wrote:
>> >> Neither of those are desirable outcomes, I think; and if we add a
>> >> separate "XDP multi-buff" switch, we might as well make it system-wide?  
>> >
>> > If we have an internal flag 'this driver supports multi-buf xdp' cannot we
>> > make xdp_redirect to linearize in case the packet is being redirected
>> > to non multi-buf aware driver (potentially with corresponding non mb aware xdp
>> > progs attached) from mb aware driver?  
>> 
>> Hmm, the assumption that XDP frames take up at most one page has been
>> fundamental from the start of XDP. So what does linearise mean in this
>> context? If we get a 9k packet, should we dynamically allocate a
>> multi-page chunk of contiguous memory and copy the frame into that, or
>> were you thinking something else?
>
> My $.02 would be to not care about redirect at all.
>
> It's not like the user experience with redirect is anywhere close 
> to amazing right now. Besides (with the exception of SW devices which
> will likely gain mb support quickly) mixed-HW setups are very rare.
> If the source of the redirect supports mb so will likely the target.

It's not about device support it's about XDP program support: If I run
an MB-aware XDP program on a physical interface and redirect the (MB)
frame into a container, and there's an XDP program running inside that
container that isn't MB-aware, bugs will ensue. Doesn't matter if the
veth driver itself supports MB...

We could leave that as a "don't do that, then" kind of thing, but that
was what we were proposing (as the "do nothing" option) and got some
pushback on, hence why we're having this conversation :)

-Toke

```