[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201104125348.GB11993@lore-desk>
Date: Wed, 4 Nov 2020 13:53:48 +0100
From: Lorenzo Bianconi <lorenzo.bianconi@...hat.com>
To: Jesper Dangaard Brouer <brouer@...hat.com>
Cc: Lorenzo Bianconi <lorenzo@...nel.org>, netdev@...r.kernel.org,
bpf@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
ilias.apalodimas@...aro.org, Ioana Ciornei <ioana.ciornei@....com>,
Ioana Radulescu <ruxandra.radulescu@....com>
Subject: Re: [PATCH v3 net-next 1/5] net: xdp: introduce bulking for xdp tx
return path
> On Wed, 4 Nov 2020 12:19:02 +0100
> Lorenzo Bianconi <lorenzo.bianconi@...hat.com> wrote:
>
> > > On Wed, 4 Nov 2020 11:22:54 +0100
> > > Lorenzo Bianconi <lorenzo@...nel.org> wrote:
> > >
> >
> > [...]
> >
> > > > +/* XDP bulk APIs introduce a defer/flush mechanism to return
> > > > + * pages belonging to the same xdp_mem_allocator object
> > > > + * (identified via the mem.id field) in bulk to optimize
> > > > + * I-cache and D-cache.
> > > > + * The bulk queue size is set to 16 to be aligned to how
> > > > + * XDP_REDIRECT bulking works. The bulk is flushed when
> > >
> > > If this is connected, then why have you not redefined DEV_MAP_BULK_SIZE?
> > >
> > > Cc. DPAA2 maintainers as they use this define in their drivers.
> > > You want to make sure this driver is flexible enough for future changes.
> > >
> > > Like:
> > >
> > > diff --git a/include/net/xdp.h b/include/net/xdp.h
> > > index 3814fb631d52..44440a36f96f 100644
> > > --- a/include/net/xdp.h
> > > +++ b/include/net/xdp.h
> > > @@ -245,6 +245,6 @@ bool xdp_attachment_flags_ok(struct xdp_attachment_info *info,
> > > void xdp_attachment_setup(struct xdp_attachment_info *info,
> > > struct netdev_bpf *bpf);
> > >
> > > -#define DEV_MAP_BULK_SIZE 16
> > > +#define DEV_MAP_BULK_SIZE XDP_BULK_QUEUE_SIZE
> >
> > my idea was to address it in a separated patch, but if you prefer I can merge
> > this change in v4
sure, will do in v4.
Regards,
Lorenzo
>
> Please merge in V4. As this patch contains the explanation, and we
> want to avoid too much churn (remember our colleagues need to backport
> and review this).
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
>
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists