netdev - Re: [xdp-hints] Re: [PATCH bpf-next v2 6/8] mlx4: Introduce mlx4_xdp_buff wrapper for xdp

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, 24 Nov 2022 17:11:34 +0100
From:   Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
CC:     Jakub Kicinski <kuba@...nel.org>, <sdf@...gle.com>,
        <bpf@...r.kernel.org>, <ast@...nel.org>, <daniel@...earbox.net>,
        <andrii@...nel.org>, <martin.lau@...ux.dev>, <song@...nel.org>,
        <yhs@...com>, <john.fastabend@...il.com>, <kpsingh@...nel.org>,
        <haoluo@...gle.com>, <jolsa@...nel.org>,
        Tariq Toukan <tariqt@...dia.com>,
        David Ahern <dsahern@...il.com>,
        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] Re: [PATCH bpf-next v2 6/8] mlx4: Introduce
 mlx4_xdp_buff wrapper for xdp_buff

On Thu, Nov 24, 2022 at 04:17:01PM +0100, Maciej Fijalkowski wrote:
> On Thu, Nov 24, 2022 at 03:39:20PM +0100, Toke Høiland-Jørgensen wrote:
> > Jakub Kicinski <kuba@...nel.org> writes:
> > 
> > > On Wed, 23 Nov 2022 22:55:21 +0100 Toke Høiland-Jørgensen wrote:
> > >> > Good idea, prototyped below, lmk if it that's not what you had in mind.
> > >> >
> > >> > struct xdp_buff_xsk {
> > >> > 	struct xdp_buff            xdp;                  /*     0    56 */
> > >> > 	u8                         cb[16];               /*    56    16 */
> > >> > 	/* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */  
> > >> 
> > >> As pahole helpfully says here, xdp_buff is actually only 8 bytes from
> > >> being a full cache line. I thought about adding a 'cb' field like this
> > >> to xdp_buff itself, but figured that since there's only room for a
> > >> single pointer, why not just add that and let the driver point it to
> > >> where it wants to store the extra context data?
> > >
> > > What if the driver wants to store multiple pointers or an integer or
> > > whatever else? The single pointer seems quite arbitrary and not
> > > strictly necessary.
> > 
> > Well, then you allocate a separate struct and point to that? Like I did
> > in mlx5:
> > 
> > 
> > +	struct mlx5_xdp_ctx mlctx = { .cqe = cqe, .rq = rq };
> > +	struct xdp_buff xdp = { .drv_priv = &mlctx };
> > 
> > but yeah, this does give an extra pointer deref on access. I'm not
> > really opposed to the cb field either, I just think it's a bit odd to
> > put it in struct xdp_buff_xsk; that basically requires the driver to
> > keep the layouts in sync.
> > 
> > Instead, why not but a cb field into xdp_buff itself so it can be used
> > for both the XSK and the non-XSK paths? Then the driver can just
> > typecast the xdp_buff into its own struct that has whatever data it
> > wants in place of the cb field?
> 
> Why can't you simply have a pointer to xdp_buff in driver specific
> xdp_buff container which would point to xdp_buff that is stack based (or
> whatever else memory that will back it up - I am about to push a change
> that makes ice driver embed xdp_buff within a struct that represents Rx
> ring) for XDP path and for ZC the pointer to xdp_buff that you get from
> xsk_buff_pool ? This would satisfy both sides I believe and would let us
> keep the same container struct.
> 
> struct mlx4_xdp_buff {
> 	struct xdp_buff *xdp;
> 	struct mlx4_cqe *cqe;
> 	struct mlx4_en_dev *mdev;
> 	struct mlx4_en_rx_ring *ring;
> 	struct net_device *dev;
> };

Nah this won't work from kfunc POV, probably no way to retrieve the
mlx4_xdp_buff based on xdp_buff ptr that needs to be used as an arg.

Sorry I'll think more about it, in the meantime let's hear more voices
whether we should keep Stan's original approach + modify xdp_buff_xsk or
go with Toke's proposal.

> 
> (...)
> 
> 	struct mlx4_xdp_buff mxbuf;
> 	struct xdp_buff xdp;
> 
> 	mxbuf.xdp = &xdp;
> 	xdp_init_buff(mxbuf.xdp, priv->frag_info[0].frag_stride, &ring->xdp_rxq);
> 
> Also these additional things
> 
> +			mxbuf.cqe = cqe;
> +			mxbuf.mdev = priv->mdev;
> +			mxbuf.ring = ring;
> +			mxbuf.dev = dev;
> 
> could be assigned once at a setup time or in worse case once per NAPI. So
> maybe mlx4_xdp_buff shouldn't be stack based?