Hi Saeed, > On Nov 13, 2020, at 10:02 AM, Patel, Vedang <vedang.pa...@intel.com> wrote: > > Hi Saeed, > >> On Nov 12, 2020, at 11:31 AM, Saeed Mahameed <sa...@kernel.org> wrote: >> >> On Tue, 2020-11-10 at 23:53 +0000, Patel, Vedang wrote: >>>> With BTF formatted metadata it is up to the driver to advertise >>>> whatever it can/want :) >>>> so yes. >>> >>> I have a very basic question here. From what I understand about BTF, >>> I can generate a header file (using bpftool?) containing the BTF data >>> format provided by the driver. If so, how can I design an application >>> which can work with multiple NICs drivers without recompilation? I am >>> guessing there is some sort of “master list” of HW hints the drivers >>> will agree upon? >> >> Hi Patel, as Jesper mentioned, some hints will be well defined in BTF >> format, by name, size and type, e.g.: >> >> u32 hash32; >> u16 vlan_tci; >> u64 timestamp; >> >> etc.. >> >> if the driver reports only well known hints, a program compiled with >> these can work in theory on any NIC that supports them. the BPF program >> loader/verifier in the kernel can check compatibility before loading a >> program on a NIC. >> >> now the question remains, What if different NICs/Drivers re-arrange >> those fields differently? >> this also can be solved by the BPF XDP program loader in the kernel at >> rung time, it can re-arrange the meta data offsets according to the >> current NIC directly in the byte code, but this is going to be a future >> work. >> > Thanks for more info! > > I have pulled in your changes and started modifying the igc driver. I will > report back on how it goes. > I was able to add support for igc and now I have a few more opens about the feature: - i225 contains multiple PHC clocks which can report timestamps for a packet. So, along with the timestamp, we also need to return clock id which was used to timestamp the packet. I was wondering if there are other NICs which have similar functionalities so that we can align on the interface used to present the timestamp to AF_XDP sockets. - I am also planning to add capability to set timestamp using AF_XDP socket. I am just planning to add another socket option (like what is done in AF_PACKET). Let me know if there are other ideas. - From what I understand metadata size will be accounted for in the XDP_PACKET_HEADROOM. Is that correct? If so, what will happen in the scenario when the metadata exceeds the amount of space available (XDP_PACKET_HEADROOM - sizeof(struct xdp_frame))? - From looking at the code, it looks like BTF metadata will be enabled at NIC level. So, all AF_XDP sockets will receive metadata whether they want it or not. Do we need a knob for AF_XDP sockets to enable metadata? I think applications which expect larger frame size will not want metadata in order to save space.
Thanks, Vedang > Thanks, > Vedang
