On 2018-12-19 00:04, Alexei Starovoitov wrote:
On Mon, Dec 17, 2018 at 04:30:05PM +0100, Björn Töpel wrote:
Instead of introducing the XDP_ATTACH option to the bind call, can we
just make this association between rx queue id and xsk every single
time we bind? Then it is up to the user via the XDP program if he/she
wants to use this by calling xsk_redirect. No new option needed.
Nice! Then it would simply be a matter of adding the helper. Much better
than extending the uapi. Thank you for pointing this out!
Magnus's by-default association approach sounds good to me.
I'm missing though why extra bpf helper is needed.
This soft-bind rx queue with xsk at the time
of normal bind() should work as-is and no program necessary.
Hmm, an XDP program has always been required. It's just whether the
program needs an XSKMAP or not. The XDP_ATTACH can be seens as "use an
internal map" -- and the mechanism to redirect using that map is via the
bpf_xsk_redirect helper. What Magnus proposed was populating the builtin
map unconditionally, and therefore removing the need for the XDP_ATTACH
option.
If I am interpreting what you're saying correctly, you thought
XDP_ATTACH (in v1) was bypassing the XDP path. This is not something
that we want. AF_XDP is a proper XDP construct, and require an XDP
program to receive frames. What I wanted to improve with this series was
to lower the complexity of the minimal XDP program to receive a frame.
No prog -> default assoc. Yet the prog has an ability to redirect
to specific xsk via existing bpf_redirect_map
or via faster (future) xsk_redirect.
Also I agree with Jesper that per-queue programs would be good to have
sooner than later, but I disagree that it's mandatory for this set.
It seems the patches will give us performance boost and simplification
of uapi while per-queue prog api is being discussed and implemented.
I like the other idea too (of having libbpf provide canned bpf progs
for different use cases). That's better than loading them
from the kernel.
To summarize; I'll hold off this series for now (except the first
cleanup patch which I'll send out today), and spend some time on
per-queue programs, iproute2 support and libbpf.
Björn
