> On Nov 18, 2020, at 4:57 PM, Patel, Vedang <vedang.pa...@intel.com> wrote:
>
> 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.
Looking a bit more into the code, the only think which is required to enable
timestamping to issue ioctl() call to the driver which is already implemented
for i225. So, there is no change required in the XDP infrastructure for this.
> - 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
