linux-kernel - Re: [RFC PATCH net-next V2 0/6] XDP rx handler

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: <20180815053550.5g4f5qeb7r4wtgm5@ast-mbp>
Date:   Tue, 14 Aug 2018 22:35:51 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     David Ahern <dsahern@...il.com>,
        Jesper Dangaard Brouer <jbrouer@...hat.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        ast@...nel.org, daniel@...earbox.net, mst@...hat.com
Subject: Re: [RFC PATCH net-next V2 0/6] XDP rx handler

On Wed, Aug 15, 2018 at 08:29:45AM +0800, Jason Wang wrote:
> 
> Looks less flexible since the topology is hard coded in the XDP program
> itself and this requires all logic to be implemented in the program on the
> root netdev.
> 
> > 
> > I have L3 forwarding working for vlan devices and bonds. I had not
> > considered macvlans specifically yet, but it should be straightforward
> > to add.
> > 
> 
> Yes, and all these could be done through XDP rx handler as well, and it can
> do even more with rather simple logic:
> 
> 1 macvlan has its own namespace, and want its own bpf logic.
> 2 Ruse the exist topology information for dealing with more complex setup
> like macvlan on top of bond and team. There's no need to bpf program to care
> about topology. If you look at the code, there's even no need to attach XDP
> on each stacked device. The calling of xdp_do_pass() can try to pass XDP
> buff to upper device even if there's no XDP program attached to current
> layer.
> 3 Deliver XDP buff to userspace through macvtap.

I think I'm getting what you're trying to achieve.
You actually don't want any bpf programs in there at all.
You want macvlan builtin logic to act on raw packet frames.
It would have been less confusing if you said so from the beginning.
I think there is little value in such work, since something still
needs to process this raw frames eventually. If it's XDP with BPF progs
than they can maintain the speed, but in such case there is no need
for macvlan. The first layer can be normal xdp+bpf+xdp_redirect just fine.
In case where there is no xdp+bpf in final processing, the frames are
converted to skb and performance is lost, so in such cases there is no
need for builtin macvlan acting on raw xdp frames either. Just keep
existing macvlan acting on skbs.