netdev - Re: Hardware time stamping support for AF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <B51B5C91-D388-4BF4-97B2-0A4AF5B365A4@intel.com>
Date:   Thu, 19 Nov 2020 00:57:17 +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

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.
- 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