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: <CAJ8uoz0DZXMVYETSzjWY-VGfy0vi7tYMod7_9E395B1x+-zJEw@mail.gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ