On Tue, 21 Sep 2021 18:06:35 +0200 Toke Høiland-Jørgensen wrote:
1. Do nothing. This would make it up to users / sysadmins to avoid
anything breaking by manually making sure to not enable multi-buffer
support while loading any XDP programs that will malfunction if
presented with an mb frame. This will probably break in interesting
ways, but it's nice and simple from an implementation PoV. With this
we don't need the declaration discussed above either.
2. Add a check at runtime and drop the frames if they are mb-enabled and
the program doesn't understand it. This is relatively simple to
implement, but it also makes for difficult-to-understand issues (why
are my packets suddenly being dropped?), and it will incur runtime
overhead.
3. Reject loading of programs that are not MB-aware when running in an
MB-enabled mode. This would make things break in more obvious ways,
and still allow a userspace loader to declare a program "MB-aware" to
force it to run if necessary. The problem then becomes at what level
to block this?
Doing this at the driver level is not enough: while a particular
driver knows if it's running in multi-buff mode, we can't know for
sure if a particular XDP program is multi-buff aware at attach time:
it could be tail-calling other programs, or redirecting packets to
another interface where it will be processed by a non-MB aware
program.
So another option is to make it a global toggle: e.g., create a new
sysctl to enable multi-buffer. If this is set, reject loading any XDP
program that doesn't support multi-buffer mode, and if it's unset,
disable multi-buffer mode in all drivers. This will make it explicit
when the multi-buffer mode is used, and prevent any accidental subtle
malfunction of existing XDP programs. The drawback is that it's a
mode switch, so more configuration complexity.
4. Add new program type, XDP_MB. Do not allow mixing of XDP vs XDP_MB
thru tail calls.
IMHO that's very simple and covers majority of use cases.