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

John W. Linville linville at tuxdriver.com
Fri Jul 11 17:33:10 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... :-)

-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


More information about the dev mailing list