Thread (53 messages) 53 messages, 11 authors, 2021-07-06

Re: [PATCH v9 bpf-next 01/14] net: skbuff: add data_len field to skb_shared_info

flat view

From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-06-29 18:37:21
Also in: bpf

On Tue, 29 Jun 2021 11:18:38 -0700 Alexander Duyck wrote:
On Tue, Jun 29, 2021 at 10:08 AM Jakub Kicinski [off-list ref] wrote:
quoted
quoted
ack, I agree. I will fix it in v10.  
Why is XDP mb incompatible with LRO? I thought that was one of the use
cases (mentioned by Willem IIRC).  
XDP is meant to be a per packet operation with support for TX and
REDIRECT, and LRO isn't routable. So we could put together a large LRO
frame but we wouldn't be able to break it apart again. If we allow
that then we are going to need a ton more exception handling added to
the XDP paths.

As far as GSO it would require setting many more fields in order to
actually make it offloadable by any hardware.
It would require more work, but TSO seems to be explicitly stated 
as what the series builds towards (in the cover letter). It's fine
to make choices we'd need to redo later, I guess, I'm just trying
to understand the why.
My preference would be
to make use of gso_segs and gso_size to store the truesize and datalen
of the pages. That way we keep all of the data fields used in the
shared info in the first 8 bytes assuming we don't end up having to
actually use multiple buffers.
Is 8B significant? We expect the compiler to load 8B and then slice it
out? Can the CPU do that? We're not expecting sinfo to be misaligned
(e.g. placed directly after xdp_buff), right?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help