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

["John W. Linville" <linville@tuxdriver.com>]

On Fri, Jun 06, 2014 at 04:30:50PM -0400, Neil Horman wrote:
> On Fri, Jun 06, 2014 at 03:25:54PM -0400, John W. Linville wrote:
> > This is a Linux-specific virtual PMD driver backed by an AF_PACKET
> > socket.  The current implementation uses mmap'ed ring buffers to
> > limit copying and user/kernel transitions.  The intent is also to take
> > advantage of fanout and any future AF_PACKET optimizations as well.
> > 
> > This is intended to provide a means for using DPDK on a broad range
> > of hardware without hardware-specifi PMDs and hopefully with better
> > performance than what PCAP offers in Linux.  This might be useful
> > as a development platform for DPDK applications when DPDK-supported
> > hardware is expensive or unavailable.
> > 
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > I've been toying with this for a while without a lot of progress.
> > I was about to post the original RFC patch just as the PMD
> > initialization flows got rewritten.  I set this down while that was
> > settling-out, and only just recently got back to it.
> > 
> > Anyway, I figure it is better to get this out now and let people
> > comment on it and/or get some use out of it if they can.  I have
> > posted this as RFC as it has only had very limited testing locally
> > and I'm sure it still could use some clean-ups and improvements
> > (like parameterizing block/frame size/count).
> > 
> Looks pretty good.  I'll be interested to see how much beter we can do over
> standard pcap when we turn on the features like fanout and increased memory
> sizing.
> 
> 
> One thought: Its not a feature, but is there advantage to making the transmit
> batch size configurable?  e.g. how many packets you queue up for transmit in a
> given memory buffer before calling send?  If you couple that with a timer, you
> could trade of some initial latency for higher overall througput, as it reduces
> the number of syscall traps you have to make.

Sure.  For now, that is gated on the number of packets passed to the
transmit function.  But I gather you are thinking of a bigger number
that the PMD would manage across multiple transmit batches?  In concept
that is similar to how 802.11n bundles frames into aggregates to reduce
the cost of contending for the media.  As you say, latency suffers,
but throughput can be improved.

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