On 2018-12-17 13:50, Jesper Dangaard Brouer wrote:
On Mon, 17 Dec 2018 11:24:54 +0100 Björn Töpel <bjorn.to...@gmail.com> wrote:XDP_ATTACH associates an XDP socket to a specific netdev Rx queue. To redirect a packet to an attached socket from XDP, the bpf_xsk_redirect helper is used. The bpf_xsk_redirect helper is also introduced in this series. Many XDP socket users just need a simple way of creating/binding a socket and receiving frames right away without a complicated XDP program. "Attached" XDP sockets removes the need for the XSKMAP, and allows for a trivial XDP program, e.g.: SEC("xdp") int xdp_prog(struct xdp_md *ctx) { return bpf_xsk_redirect(ctx); } An attached XDP socket also has better performance than the XSKMAP based sockets (performance numbers below).I still have a general problem with this approach.
And I appreciate that you have comments on the design/code! :-) Thank you!
The AF_XDP socket is build around (and gets its performance) from being tied to a specific RX-queue. That design begs to have an XDP program per RX-queue. Patchset-v1 moved towards this goal. But in this patchset-v2 you steer away from this again, and work-around the issue with the current limitations of 1-XDP program per netdev. (Which result in; if a single AF_XDP socket is used in the system, which can ONLY be for a single RX-queue by design, then ALL other XDP_PASS traffic also have to take the overhead of indirect BPF call).
I agree that a per-queue-program would be a good fit, but I think it still makes sense to add XDP_ATTACH and the helper, to make it easier for the XDP program authors to use AF_XDP. Would you prefer that this functionality was help back, until per-queue programs are introduced? OTOH the implementation would probably look different if there was a per-q program, because this would open up for more optimizations. One could even imagine that the socket fd was part of the program (part of relocation process) when loading the program. That could get rid of yet another if-statement that check for socket existence. :-)
IMHO with this use-case, now is the time to introduce XDP programs per RX-queue. Yes, it will be more work, but I will offer to helpout. This should be generalized as XDP programs per RX-queue can be used by other use-cases too: In general terms: We can setup a NIC hardware filter to deliver frame matching some criteria, then we can avoid rechecking these criterias in on the (RX) CPU when/if we can attach an XDP prog to this specific RX-queue directly. This *IS* exactly what AF_XDP does, but it is in general useful for others, like CPUMAP redirect.
Fair enough, and thank you for offering to help out. And the fact that *other than AF_XDP* can benefit from that is good. Before we dive down this hole, what are the opinions of the BPF maintainers? Maybe it's better to hack an RFC, and then take the discussion? Björn
