From: Jesper Dangaard Brouer <jbrouer@xxxxxxxxxx> Date: Tue, 24 Jan 2023 13:23:49 +0100 > > On 24/01/2023 12.49, Toke Høiland-Jørgensen wrote: >> Alexander Lobakin <alexandr.lobakin@xxxxxxxxx> writes: >> >>> From: Stanislav Fomichev <sdf@xxxxxxxxxx> >>> Date: Mon, 23 Jan 2023 10:55:52 -0800 >>> >>>> On Mon, Jan 23, 2023 at 10:53 AM Martin KaFai Lau >>>> <martin.lau@xxxxxxxxx> wrote: >>>>> >>>>> On 1/19/23 2:15 PM, Stanislav Fomichev wrote: >>>>>> Please see the first patch in the series for the overall >>>>>> design and use-cases. >>>>>> >>>>>> See the following email from Toke for the per-packet metadata >>>>>> overhead: >>>>>> https://lore.kernel.org/bpf/20221206024554.3826186-1-sdf@xxxxxxxxxx/T/#m49d48ea08d525ec88360c7d14c4d34fb0e45e798 >>>>>> >>>>>> Recent changes: >>>>>> - Keep new functions in en/xdp.c, do 'extern >>>>>> mlx5_xdp_metadata_ops' (Tariq) >>>>>> >>>>>> - Remove mxbuf pointer and use xsk_buff_to_mxbuf (Tariq) >>>>>> >>>>>> - Clarify xdp_buff vs 'XDP frame' (Jesper) >>>>>> >>>>>> - Explicitly mention that AF_XDP RX descriptor lacks metadata size >>>>>> (Jesper) >>>>>> >>>>>> - Drop libbpf_flags/xdp_flags from selftests and use ifindex instead >>>>>> of ifname (due to recent xsk.h refactoring) >>>>> >>>>> Applied with the minor changes in the selftests discussed in patch >>>>> 11 and 17. >>>>> Thanks! >>>> >>>> Awesome, thanks! I was gonna resend around Wed, but thank you for >>>> taking care of that! >>> Great stuff, congrats! :) >> >> Yeah! Thanks for carrying this forward, Stanislav! :) > > +1000 -- great work everybody! :-) > > To Alexander (Cc Jesse and Tony), do you think someone from Intel could > look at extending drivers: > > drivers/net/ethernet/intel/igb/ - chip i210 > drivers/net/ethernet/intel/igc/ - chip i225 > drivers/net/ethernet/stmicro/stmmac - for CPU integrated LAN ports Sorry, just noticed :s I work with ice only, but seems like the responsible teams started some work already. At least for i225. They may write some follow-ups soon. > > We have a customer that have been eager to get hardware RX-timestamping > for their AF_XDP use-case (PoC code[1] use software timestamping via > bpf_ktime_get_ns() today). Getting driver support will qualify this > hardware as part of their HW solution. > > --Jesper > [1] > https://github.com/xdp-project/bpf-examples/blob/master/AF_XDP-interaction/af_xdp_kern.c#L77 > Thanks, Olek