[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

Venkatesan, Venky venky.venkatesan at intel.com
Fri Jul 11 18:29:11 CEST 2014


On Fri, Jul 11, 2014 at 03:29:17PM +0000, Venkatesan, Venky wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John W. 
> > Linville
> > Sent: Friday, July 11, 2014 7:49 AM
> > To: Stephen Hemminger
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > AF_PACKET- based virtual devices
> > 
> > On Fri, Jul 11, 2014 at 06:11:47AM -0700, Stephen Hemminger wrote:
> > > On Thu, 10 Jul 2014 16:32:49 -0400 "John W. Linville" 
> > > <linville at tuxdriver.com> wrote:
> > >
> > > > This is a Linux-specific virtual PMD driver backed by an 
> > > > AF_PACKET

<snip>

> > > > +struct pkt_rx_queue {
> > > > +	int sockfd;
> > > > +
> > > > +	struct iovec *rd;
> > > > +	uint8_t *map;
> > > > +	unsigned int framecount;
> > > > +	unsigned int framenum;
> > > > +
> > > > +	struct rte_mempool *mb_pool;
> > > > +
> > > > +	volatile unsigned long rx_pkts;
> > > > +	volatile unsigned long err_pkts;
> > >
> > > Use of volatile will generate slow code, don't think it is 
> > > necessary, especially when only one CPU can use a queue at a time.
> > 
> > That is a good point, worth checking out.  FWIW, those lines are 
> > boilerplate originally copied from the pcap PMD. :-)
> > 
> 
> > Yes, I agree it's worth checking out if there is a performance 
> > impact, but if we assume that the stats for RX/TX are possibly going 
> > to be read by another core, they really should be volatile for 
> > correctness
> 
> Accessing the rx_queue structure directly for stats is unlikely to happen from a second core; we should probably change the PCAP PMD as well (thanks for pointing that out John). 

> "Unlikely" doesn't sound completely safe... :-)

LOL. :-). This is an internal data structure and the DPDK docs specifically mention that they are not  multi-process safe/accessible. The unlikely was for people that don't read the docs ... ;)



More information about the dev mailing list