netdev - Re: [PATCH v4 bpf-next 07/10] selftests: xsk: introduce default Rx pkt stream

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]

Date:   Mon, 20 Jun 2022 10:41:25 +0200
From:   Magnus Karlsson <magnus.karlsson@...il.com>
To:     John Fastabend <john.fastabend@...il.com>
Cc:     Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
        bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Network Development <netdev@...r.kernel.org>,
        "Karlsson, Magnus" <magnus.karlsson@...el.com>,
        Björn Töpel <bjorn@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH v4 bpf-next 07/10] selftests: xsk: introduce default Rx
 pkt stream

On Sat, Jun 18, 2022 at 4:44 AM John Fastabend <john.fastabend@...il.com> wrote:
>
> Maciej Fijalkowski wrote:
> > In order to prepare xdpxceiver for physical device testing, let us
> > introduce default Rx pkt stream. Reason for doing it is that physical
> > device testing will use a UMEM with a doubled size where half of it will
> > be used by Tx and other half by Rx. This means that pkt addresses will
> > differ for Tx and Rx streams. Rx thread will initialize the
> > xsk_umem_info::base_addr that is added here so that pkt_set(), when
> > working on Rx UMEM will add this offset and second half of UMEM space
> > will be used. Note that currently base_addr is 0 on both sides. Future
> > commit will do the mentioned initialization.
> >
> > Previously, veth based testing worked on separate UMEMs, so single
> > default stream was fine.
> >
> > Acked-by: Magnus Karlsson <magnus.karlsson@...el.com>
> > Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
> > ---
>
> Just curious why can't we make veth use a single umem with double size?
> Would be nice to have a single test setup. Why choose two vs a single
> size.

Good point. We could do that, but I prefer if we keep the two modes as
one uses the XDP_SHARED_UMEM feature and the other one does not as it
uses private umems. The more modes we can test, the better. But what
we should do is test both modes when possible and also the third mode
when a umem is shared between separate queue ids and netdevs,
something we do not test at all today. So I say, keep it like this for
now and I can submit another patch set that extends the veth tests to
also use a shared umem (the double umem size case) and introduce
testing of the third mode when applicable.

> Thanks.