Re: [PATCH bpf-next v2 0/7] Add support for XDP_ATTACH

[Jesper Dangaard Brouer <brouer@redhat.com>]

On Mon, 17 Dec 2018 11:24:54 +0100
Björn Töpel <bjorn.topel@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