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

[Neil Horman <nhorman@tuxdriver.com>]

On Fri, Jun 06, 2014 at 04:36:11PM -0400, John W. Linville wrote:
> 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.
> 
Exatly, yes.  Not sure if its helpful here, but might be good for future
consideration
Neil

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