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 at 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 at tuxdriver.com might be all we have. Be ready. >
