> On Fri, 18 Jul 2025 12:56:46 +0200 Jesper Dangaard Brouer wrote: > > >> Thanks for the feedback. I can see why you'd be concerned about adding > > >> another adhoc scheme or making xdp_frame grow into a "para-skb". > > >> > > >> However, I'd like to frame this as part of a long-term plan we've been > > >> calling the "mini-SKB" concept. This isn't a new idea, but a > > >> continuation of architectural discussions from as far back as [2016]. > > > > > > My understanding is that while this was floated as a plan by some, > > > nobody came up with a clean way of implementing it. > > > > I can see why you might think that, but from my perspective, the > > xdp_frame *is* the implementation of the mini-SKB concept. We've been > > building it incrementally for years. It started as the most minimal > > structure possible and has gradually gained more context (e.g. dev_rx, > > mem_info/rxq_info, flags, and also uses skb_shared_info with same layout > > as SKB). > > My understanding was that just adding all the fields to xdp_frame was > considered too wasteful. Otherwise we would have done something along > those lines ~10 years ago :S Hi Jakub, sorry for the late reply. I am completely fine to redesign the solution to overcome the problem but I guess this feature will allow us to improve XDP performance in a common/real use-case. Let's consider we want to redirect a packet into a veth and then into a container. Preserving the hw metadata performing XDP_REDIRECT will allow us to avoid recalculating the checksum creating the skb. This will result in a very nice performance improvement. So I guess we should really come up with some idea to add this missing feature. Regards, Lorenzo > > > This patch is simply the next logical step in that existing evolution: > > adding hardware metadata to make it more capable, starting with enabling > > XDP_REDIRECT offloads. The xdp_frame is our mini-SKB, and this patchset > > continues its evolution. > > I thought one of the goals for mini-skb was to move the skb allocation > out of the drivers. The patches as posted seem to make it the > responsibility of the XDP program to save the metadata. If you're > planning to make drivers populate this metadata by default - why add > the helpers. > > Again, I just don't understand how these logically fit into place > vis-a-vis the existing metadata "get" callbacks.
Attachment:
signature.asc
Description: PGP signature
