Message-ID: <75C650F1-1383-47AD-96CA-B39990BA0AB3@intel.com>
Date:   Fri, 20 Nov 2020 01:06:53 +0000
From:   "Patel, Vedang" <vedang.patel@...el.com>
To:     Saeed Mahameed <saeed@...nel.org>
CC:     Jesper Dangaard Brouer <jbrouer@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Gomes, Vinicius" <vinicius.gomes@...el.com>,
        "Guedes, Andre" <andre.guedes@...el.com>
Subject: Re: Hardware time stamping support for AF_XDP applications



> On Nov 18, 2020, at 4:57 PM, Patel, Vedang <vedang.patel@...el.com> wrote:
> 
> Hi Saeed,
> 
>> On Nov 13, 2020, at 10:02 AM, Patel, Vedang <vedang.patel@...el.com> wrote:
>> 
>> Hi Saeed,
>> 
>>> On Nov 12, 2020, at 11:31 AM, Saeed Mahameed <saeed@...nel.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

Powered by blists - more mailing lists