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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181217135035.0d75aa32@redhat.com>
Date:   Mon, 17 Dec 2018 13:50:35 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Björn Töpel <bjorn.topel@...il.com>
Cc:     magnus.karlsson@...el.com, magnus.karlsson@...il.com,
        ast@...nel.org, daniel@...earbox.net, netdev@...r.kernel.org,
        Björn Töpel 
        <bjorn.topel@...el.com>, u9012063@...il.com, qi.z.zhang@...el.com,
        jakub.kicinski@...ronome.com, andrew@...n.ch, brouer@...hat.com
Subject: Re: [PATCH bpf-next v2 0/7] Add support for XDP_ATTACH

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