On Mon, 17 Dec 2018 14:39:57 +0100
Björn Töpel <bjorn.to...@intel.com> wrote:
> 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?
Yes, for the reasons you yourself listed in next section:
> 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. :-)
Yes, exactly. The implementation would probably look different, when
we look at it from a more generic angle, with per-q programs.
> > 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?
As XDP grows, and more use-cases are added, then I fear that the single
XDP program per netdev is going to be a performance bottleneck. As the
single XDP program, will have to perform a lot of common checks before
it knows what use-case this packet match. With an XDP program per
RX-queue, we can instead leverage the hardware to pre-filter/sort
packets, and thus simplify the XDP programs.
And this patchset already do shows a performance advantage of
simplifying the XDP prog and allowing to store info per RX-queue (the
xsk-sock) that allows you do take a more direct action (avoiding exec
some of the redirect-core code).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
