netdev - Re: [PATCH] net-xdp: netdev attribute to control xdpgeneric skb linearization

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: <CAMOZA0KL1p8ojK2t9hk3RDD35nN+ZuQfAOkodabZ=07p+Z8ucA@mail.gmail.com>
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
>