RE: [PATCH v5 0/3] Recycle buffers from Tx to Rx

[Feifei Wang <Feifei.Wang2@arm.com>]

Thanks for the reviewing.

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, March 30, 2023 11:05 PM
> To: Feifei Wang <Feifei.Wang2@arm.com>
> Cc: dev@dpdk.org; konstantin.v.ananyev@yandex.ru;
> mb@smartsharesystems.com; nd <nd@arm.com>
> Subject: Re: [PATCH v5 0/3] Recycle buffers from Tx to Rx
> 
> On Thu, 30 Mar 2023 14:29:36 +0800
> Feifei Wang <feifei.wang2@arm.com> wrote:
> 
> > Currently, the transmit side frees the buffers into the lcore cache
> > and the receive side allocates buffers from the lcore cache. The
> > transmit side typically frees 32 buffers resulting in 32*8=256B of
> > stores to lcore cache. The receive side allocates 32 buffers and
> > stores them in the receive side software ring, resulting in 32*8=256B
> > of stores and 256B of load from the lcore cache.
> >
> > This patch proposes a mechanism to avoid freeing to/allocating from
> > the lcore cache. i.e. the receive side will free the buffers from
> > transmit side directly into its software ring. This will avoid the
> > 256B of loads and stores introduced by the lcore cache. It also frees
> > up the cache lines used by the lcore cache. And we can call this mode
> > as buffer recycle mode.
> 
> 
> My naive reading of this is that lcore cache update is slow on ARM so you are
> introducing yet another cache. Perhaps a better solution would be to figure
> out/optimize the lcore cache to work better.

From my point of view, 'recycle buffer' is a strategic optimization. It reduces the operation
of a buffer. Not only arm, but also x86 and other  architecture can benefit from this. For example,
we can see x86 sse path performance improvement in cover letter test results.

> 
> Adding another layer of abstraction is not going to help everyone and the
> implementation you chose requires modifications to drivers to get it to work.
> 
We did not change the original driver mechanism. Recycle buffer can be looked
at a feature for pmd, if the user needs  higher performance, he/she can choose to
call the API in the application to enable it.

> In current form, this is not acceptable.