netdev - Re: [xdp-hints] [PATCH bpf-next 2/2] mlx5: Support XDP RX metadata

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]

Message-ID: <CAKH8qBueYO_8h292bayYq1CeS3U4Phv4hr=zjDWz87nmZ9eyhg@mail.gmail.com>
Date:   Wed, 23 Nov 2022 14:44:58 -0800
From:   Stanislav Fomichev <sdf@...gle.com>
To:     Saeed Mahameed <saeed@...nel.org>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        bpf@...r.kernel.org, John Fastabend <john.fastabend@...il.com>,
        David Ahern <dsahern@...il.com>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Jakub Kicinski <kuba@...nel.org>,
        Willem de Bruijn <willemb@...gle.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Anatoly Burakov <anatoly.burakov@...el.com>,
        Alexander Lobakin <alexandr.lobakin@...el.com>,
        Magnus Karlsson <magnus.karlsson@...il.com>,
        Maryam Tahhan <mtahhan@...hat.com>, xdp-hints@...-project.net,
        netdev@...r.kernel.org
Subject: Re: [xdp-hints] [PATCH bpf-next 2/2] mlx5: Support XDP RX metadata

On Wed, Nov 23, 2022 at 2:29 PM Saeed Mahameed <saeed@...nel.org> wrote:
>
> On 23 Nov 15:46, Toke Høiland-Jørgensen wrote:
> >Support RX hash and timestamp metadata kfuncs. We need to pass in the cqe
> >pointer to the mlx5e_skb_from* functions so it can be retrieved from the
> >XDP ctx to do this.
> >
> >Cc: John Fastabend <john.fastabend@...il.com>
> >Cc: David Ahern <dsahern@...il.com>
> >Cc: Martin KaFai Lau <martin.lau@...ux.dev>
> >Cc: Jakub Kicinski <kuba@...nel.org>
> >Cc: Willem de Bruijn <willemb@...gle.com>
> >Cc: Jesper Dangaard Brouer <brouer@...hat.com>
> >Cc: Anatoly Burakov <anatoly.burakov@...el.com>
> >Cc: Alexander Lobakin <alexandr.lobakin@...el.com>
> >Cc: Magnus Karlsson <magnus.karlsson@...il.com>
> >Cc: Maryam Tahhan <mtahhan@...hat.com>
> >Cc: Stanislav Fomichev <sdf@...gle.com>
> >Cc: xdp-hints@...-project.net
> >Cc: netdev@...r.kernel.org
> >Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
> >---
> >This goes on top of Stanislav's series, obvioulsy. Verified that it works using
> >the xdp_hw_metadata utility; going to do ome benchmarking and follow up with the
> >results, but figured I'd send this out straight away in case others wanted to
> >play with it.
> >
> >Stanislav, feel free to fold it into the next version of your series if you
> >want!
> >
>
> [...]
>
> > #endif /* __MLX5_EN_XSK_RX_H__ */
> >diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> >index 14bd86e368d5..015bfe891458 100644
> >--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> >+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> >@@ -4890,6 +4890,10 @@ const struct net_device_ops mlx5e_netdev_ops = {
> >       .ndo_tx_timeout          = mlx5e_tx_timeout,
> >       .ndo_bpf                 = mlx5e_xdp,
> >       .ndo_xdp_xmit            = mlx5e_xdp_xmit,
> >+      .ndo_xdp_rx_timestamp_supported = mlx5e_xdp_rx_timestamp_supported,
> >+      .ndo_xdp_rx_timestamp    = mlx5e_xdp_rx_timestamp,
> >+      .ndo_xdp_rx_hash_supported = mlx5e_xdp_rx_hash_supported,
> >+      .ndo_xdp_rx_hash         = mlx5e_xdp_rx_hash,
>
> I hope i am not late to the party.
> but I already expressed my feelings regarding using kfunc for xdp hints,
> @LPC and @netdevconf.
>
> I think it's wrong to use indirect calls, and for many usecases the
> overhead will be higher than just calculating the metadata on the spot.
>
> so you will need two indirect calls per packet per hint..
> some would argue on some systems calculating the hash would be much faster.
> and one major reason to have the hints is to accelerate xdp edge and
> security programs with the hw provided hints.
>
> what happened with just asking the driver to place the data in a specific
> location on the headroom?

Take a look at [0], we are resolving indirect calls. We can also
always go back to unrolling those calls as was done initially in [1].

0: https://lore.kernel.org/bpf/20221121182552.2152891-3-sdf@google.com/
1: https://lore.kernel.org/bpf/20221115030210.3159213-4-sdf@google.com/

kfunc approach seems more flexible than an all-or-nothing approach
with the driver pre-filling all metadata.