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:   Thu, 12 Nov 2020 11:31:28 -0800
From:   Saeed Mahameed <saeed@...nel.org>
To:     "Patel, Vedang" <vedang.patel@...el.com>
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 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.

Powered by blists - more mailing lists