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  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:   Wed, 5 Oct 2022 15:43:42 +0200
From:   Jesper Dangaard Brouer <>
To:     Martin KaFai Lau <>,
        Stanislav Fomichev <>,
        Jesper Dangaard Brouer <>
Cc:,,,,,, Lorenzo Bianconi <>,,
        Alexei Starovoitov <>,
        Daniel Borkmann <>,
        Andrii Nakryiko <>,, Magnus Karlsson <>,
Subject: Re: [PATCH RFCv2 bpf-next 00/18] XDP-hints: XDP gaining access to HW
 offload hints via BTF

On 05/10/2022 02.25, Martin KaFai Lau wrote:
> For rx hwtimestamp, the value could be just 0 if a specific hw/driver 
> cannot provide it for all packets while some other hw can.

Keep in mind that we want to avoid having to write a (64-bit) zero into
the metadata for rx_hwtimestamp, for every packet that doesn't carry a
timestamp.  It essentially reverts back to clearing memory like with
SKBs, due to performance overhead we don't want to go that path again!

There are multiple ways to avoid having to zero init the memory.

In this patchset I have choosen have the traditional approach of flags
(u32) approach located in xdp_hints_common, e.g. setting a flag if the
field is valid (p.s. John Fastabend convinced me of this approach ;-)).
But COMBINED with: some BTF ID layouts doesn't contain some fields e.g.
the rx_timestamp, thus the code have no reason to query those flag fields.

I am intrigued to find a way to leverage bpf_core_field_exists() some
more (as proposed by Stanislav).  (As this can allow for dead-code


Powered by blists - more mailing lists