[dpdk-dev] [PATCH 1/1] net/af_xdp: shared UMEM support

[Tahhan, Maryam]

> -----Original Message-----
> From: Loftus, Ciara <ciara.loftus at intel.com>
> Sent: Thursday 17 September 2020 09:55
> To: Tahhan, Maryam <maryam.tahhan at intel.com>
> Cc: dev at dpdk.org
> Subject: RE: [PATCH 1/1] net/af_xdp: shared UMEM support
> 
> > >
> > > Kernel v5.10 will introduce the ability to efficiently share a UMEM
> > > between AF_XDP sockets bound to different queue ids on the same or
> > > different devices. This patch integrates that functionality into the AF_XDP
> PMD.
> > >
> > > A PMD will attempt to share a UMEM with others if the shared_umem=1
> > > vdev arg is set. UMEMs can only be shared across PMDs with the same
> > > mempool, up to a limited number of PMDs goverened by the size of the
> > > given mempool.
> > > Sharing UMEMs is not supported for non-zero-copy (aligned) mode.
> > >
> > > The benefit of sharing UMEM across PMDs is a saving in memory due to
> > > not having to register the UMEM multiple times. Throughput was
> > > measured to remain within 2% of the default mode (not sharing UMEM).
> > >
> > > A version of libbpf >= v0.2.0 is required and the appropriate
> > > pkg-config file for libbpf must be installed such that meson can determine
> the version.
> > >
> > > Signed-off-by: Ciara Loftus <ciara.loftus at intel.com>
> >
> > <snip>
> >
> > >
> > > +/* List which tracks PMDs to facilitate sharing UMEMs across them.
> > > +*/ struct internal_list {
> > > +TAILQ_ENTRY(internal_list) next;
> > > +struct rte_eth_dev *eth_dev;
> > > +};
> > > +
> > > +TAILQ_HEAD(internal_list_head, internal_list); static struct
> > > +internal_list_head internal_list =
> > > +TAILQ_HEAD_INITIALIZER(internal_list);
> > > +
> > > +static pthread_mutex_t internal_list_lock =
> > PTHREAD_MUTEX_INITIALIZER;
> >
> > [Tahhan, Maryam] do multiple threads typically initialize and
> > ethdev/invoke the underlying driver?
> > Most apps I've seen initialize the ports one after the other in the
> > starting thread - so if there's not multiple threads doing
> > initialization - we may want to consider removing this mutex...
> > Or maybe do you see something potentially removing a port while a port
> > is being added?
> 
> Hi Maryam,
> 
> Yes. Although unlikely, I'm not aware of any guarantee that a port A cannot
> be removed when port B is being added and since both operations can touch
> the tailq I'm inclined to keep the mutex. But I'm open to correction.
> 
> Thanks,
> Ciara
> 

No worries :) better to be safe than sorry 

> >
> > <snip>
>