On Tue, Jul 11, 2023 at 8:07 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Tue, 11 Jul 2023 19:37:23 -0700 Alexei Starovoitov wrote: > > > I hope I'm not misremembering but I think I suggested at the beginning > > > to create a structure describing packet geometry and requested offloads, > > > and for the prog fill that in. > > > > hmm. but that's what skb is for. skb == packet geometry == > > layout of headers, payload, inner vs outer, csum partial, gso params. > > > > bpf at tc layer supposed to interact with that correctly. > > If the packet is modified skb geometry should be adjusted accordingly. > > Like BPF_F_RECOMPUTE_CSUM flag in bpf_skb_store_bytes(). > > > > > All operating systems I know end up doing that, we'll end up doing > > > that as well. The question is whether we're willing to learn from > > > experience or prefer to go on a wild ride first... > > > > I don't follow. This thread was aimed to add xdp layer knobs. > > To me XDP is a driver level. > > Driver is not a layer of the networking stack, I don't think it's > a useful or meaningful anchor point for the mental model. > > We're talking about a set of functionality, we can look at how that > functionality was exposed in existing code. > > > 'struct xdp_md' along with > > BPF_F_XDP_HAS_FRAGS is the best abstraction we could do generalizing > > dma-buffers (page and multi-page) that drivers operate on. > > I think you're working against your own claim. > xdp frags explicitly reuse struct skb_shared_info. Yes they do and it's an implementation detail. skb_shared_info is convenient for drivers to fill in. xdp prog isn't aware of the exact mechanism. skb_shared_info is not exposed to a program. Not sure what point you're trying to make. > > > Everything else at driver level is too unique to generalize. > > skb layer is already doing its job. > > How can you say that drivers are impossible to generalize and than > that the skb layer "is doing its job" ie. generalizes them? Yeah. 'generalize' is a wrong word to use to describe a feature that should have the same look and feel across drivers. What I meant by 'csum impossible to generalize across drivers' is that there is no HW-only path across them. skb layer is doing it through sw fallback and combination of csum_complete/unnecessary. I'm saying that your proposal of "create a structure describing packet geometry and requested offloads" already exists and it's called skb. I see no point doing this exercise again at XDP layer.