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.
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).
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.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
