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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 13 Nov 2020 18:02:47 +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 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.

Thanks,
Vedang