Jesper Dangaard Brouer <jbrouer@xxxxxxxxxx> writes: >> hash/timestap/csum is per packet .. vlan as well depending how you look at >> it.. > > True, we cannot cache this as it is *per packet* info. > >> Sorry I haven't been following the progress of xdp meta data, but why did >> we drop the idea of btf and driver copying metdata in front of the xdp >> frame ? >> > > It took me some time to understand this new approach, and why it makes > sense. This is my understanding of the design direction change: > > This approach gives more control to the XDP BPF-prog to pick and choose > which XDP hints are relevant for the specific use-case. BPF-prog can > also skip storing hints anywhere and just read+react on value (that e.g. > comes from RX-desc). > > For the use-cases redirect, AF_XDP, chained BPF-progs, XDP-to-TC, > SKB-creation, we *do* need to store hints somewhere, as RX-desc will be > out-of-scope. I this patchset hand-waves and says BPF-prog can just > manually store this in a prog custom layout in metadata area. I'm not > super happy with ignoring/hand-waving all these use-case, but I > hope/think we later can extend this some more structure to support these > use-cases better (with this patchset as a foundation). I don't think this approach "hand-waves" the need to store the metadata, it just declares it out of scope :) Which makes sense, because "accessing the metadata" and "storing it for later use" are two different problems, where the second one build on top of the first one. I.e., once we have a way to access the data, we can build upon that to have a way to store it somewhere. > I actually like this kfunc design, because the BPF-prog's get an > intuitive API, and on driver side we can hide the details of howto > extract the HW hints. +1 >> hopefully future HW generations will do that for free .. > > True. I think it is worth repeating, that the approach of storing HW > hints in metadata area (in-front of packet data) was to allow future HW > generations to write this. Thus, eliminating the 6 ns (that I showed it > cost), and then it would be up-to XDP BPF-prog to pick and choose which > to read, like this patchset already offers. > > This patchset isn't incompatible with future HW generations doing this, > as the kfunc would hide the details and point to this area instead of > the RX-desc. While we get the "store for free" from hardware, I do > worry that reading this memory area (which will part of DMA area) is > going to be slower than reading from RX-desc. Agreed (choked on the "isn't incompatible" double negative at first). If the hardware stores the data next to the packet data, the kfuncs can just read them from there. If it turns out that we can even make the layout for some fields the same across drivers, we could even have the generic kfunc implementations just read this area (which also nicely solves the "storage" problem). -Toke
