netdev - Re: [RFC PATCH v2 bpf-next 00/15] 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]

Date:   Wed, 23 Oct 2019 21:27:01 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        John Fastabend <john.fastabend@...il.com>,
        Toshiaki Makita <toshiaki.makita1@...il.com>,
        John Fastabend <john.fastabend@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Jozsef Kadlecsik <kadlec@...filter.org>,
        Florian Westphal <fw@...len.de>,
        Pravin B Shelar <pshelar@....org>
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org,
        William Tu <u9012063@...il.com>,
        Stanislav Fomichev <sdf@...ichev.me>
Subject: Re: [RFC PATCH v2 bpf-next 00/15] xdp_flow: Flow offload to XDP

Toke Høiland-Jørgensen wrote:
> John Fastabend <john.fastabend@...il.com> writes:
> 
> > I think for sysadmins in general (not OVS) use case I would work
> > with Jesper and Toke. They seem to be working on this specific
> > problem.
> 
> We're definitely thinking about how we can make "XDP magically speeds up
> my network stack" a reality, if that's what you mean. Not that we have
> arrived at anything specific yet...

There seemed to be two thoughts in the cover letter one how to make
OVS flow tc path faster via XDP. And the other how to make other
users of tc flower software stack faster.

For the OVS case seems to me that OVS should create its own XDP datapath
if its 5x faster than the tc flower datapath. Although missing from the
data was comparing against ovs kmod so that comparison would also be
interesting. This way OVS could customize things and create only what
they need.

But the other case for a transparent tc flower XDP a set of user tools
could let users start using XDP for this use case without having to
write their own BPF code. Anyways I had the impression that might be
something you and Jesper are thinking about, general usability for
users that are not necessarily writing their own network.

> 
> And yeah, I'd also be happy to discuss what it would take to make a
> native XDP implementation of the OVS datapath; including what (if
> anything) is missing from the current XDP feature set to make this
> feasible. I must admit that I'm not quite clear on why that wasn't the
> approach picked for the first attempt to speed up OVS using XDP...
> 
> -Toke
>