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:   Thu, 23 Jan 2020 10:11:35 -0800
From:   Luigi Rizzo <lrizzo@...gle.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        "David S. Miller" <davem@...emloft.net>, sameehj@...zon.com
Subject: Re: [PATCH] net-xdp: netdev attribute to control xdpgeneric skb linearization

On Thu, Jan 23, 2020 at 10:00 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Luigi Rizzo <lrizzo@...gle.com> writes:
>
> > On Thu, Jan 23, 2020 at 7:48 AM Daniel Borkmann <daniel@...earbox.net> wrote:
...
> > There was some discussion on multi-segment xdp
> > https://www.spinics.net/lists/netdev/msg620140.html
> > https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org
> >
> > with no clear decision as far as I can tell.
> >
> > I wanted to point out that linearization might be an issue for native
> > xdp as well (specifically with NICs that do header split, LRO,
> > scatter-gather, MTU pagesize ...) and having to unconditionally pay
> > the linearization cost (or disable the above features) by just loading
> > an xdp program may be a big performance hit.
>
> Right, sure, but then I'd rather fix it for all of XDP instead of
> introduce (more) differences between native and generic mode...

FWIW I think the discussion was heading towards 'only pass the first segment
to the bpf code' with some other mechanism TBD to at least reliably know that
there is more (right now bpf can look at the protocol headers, but of
course they can lie).

Whatever the fix is, it will probably require extending xdp_buff with
extra fields.
I am not sure whether this is considered a stable ABI or one in flux...

cheers
luigi
>
> -Toke
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ