From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 554C0683A for ; Fri, 6 Jun 2014 22:51:47 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Wt17G-0002SI-6U; Fri, 06 Jun 2014 16:52:00 -0400 Date: Fri, 6 Jun 2014 16:51:57 -0400 From: Neil Horman To: "John W. Linville" Message-ID: <20140606205157.GC2543@hmsreliant.think-freely.org> References: <1402082754-12921-1-git-send-email-linville@tuxdriver.com> <20140606203050.GB2543@hmsreliant.think-freely.org> <20140606203611.GB3208@tuxdriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140606203611.GB3208@tuxdriver.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 20:51:47 -0000 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 > > > --- > > > 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. >