netdev - Re: [PATCH v4 bpf-next 00/13] mvneta: introduce XDP multi-buffer support

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: <20201005222454.GB3501@localhost.localdomain>
Date:   Tue, 6 Oct 2020 00:24:54 +0200
From:   Lorenzo Bianconi <lorenzo@...nel.org>
To:     John Fastabend <john.fastabend@...il.com>
Cc:     Jesper Dangaard Brouer <brouer@...hat.com>,
        Lorenzo Bianconi <lorenzo.bianconi@...hat.com>,
        bpf@...r.kernel.org, netdev@...r.kernel.org, davem@...emloft.net,
        kuba@...nel.org, ast@...nel.org, daniel@...earbox.net,
        shayagr@...zon.com, sameehj@...zon.com, dsahern@...nel.org,
        echaudro@...hat.com
Subject: Re: [PATCH v4 bpf-next 00/13] mvneta: introduce XDP multi-buffer
 support

[...]

> 
> In general I see no reason to populate these fields before the XDP
> program runs. Someone needs to convince me why having frags info before
> program runs is useful. In general headers should be preserved and first
> frag already included in the data pointers. If users start parsing further
> they might need it, but this series doesn't provide a way to do that
> so IMO without those helpers its a bit difficult to debate.

We need to populate the skb_shared_info before running the xdp program in order to
allow the ebpf sanbox to access this data. If we restrict the access to the first
buffer only I guess we can avoid to do that but I think there is a value allowing
the xdp program to access this data.
A possible optimization can be access the shared_info only once before running
the ebpf program constructing the shared_info using a struct allocated on the
stack.
Moreover we can define a "xdp_shared_info" struct to alias the skb_shared_info
one in order to have most on frags elements in the first "shared_info" cache line.

> 
> Specifically for XDP_TX case we can just flip the descriptors from RX
> ring to TX ring and keep moving along. This is going to be ideal on
> 40/100Gbps nics.
> 
> I'm not arguing that its likely possible to put some prefetch logic
> in there and keep the pipe full, but I would need to see that on
> a 100gbps nic to be convinced the details here are going to work. Or
> at minimum a 40gbps nic.
> 
> > 
> > 

[...]

> Not against it, but these things are a bit tricky. Couple things I still
> want to see/understand
> 
>  - Lets see a 40gbps use a prefetch and verify it works in practice
>  - Explain why we can't just do this after XDP program runs

how can we allow the ebpf program to access paged data if we do not do that?

>  - How will we read data in the frag list if we need to parse headers
>    inside the frags[].
> 
> The above would be best to answer now rather than later IMO.
> 
> Thanks,
> John

Regards,
Lorenzo

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)