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 862C65323 for ; Fri, 6 Jun 2014 22:44:54 +0200 (CEST) Received: from uucp by smtp.tuxdriver.com with local-rmail (Exim 4.63) (envelope-from ) id 1Wt10d-0002Om-Sb; Fri, 06 Jun 2014 16:45:07 -0400 Received: from linville-x1.hq.tuxdriver.com (localhost.localdomain [127.0.0.1]) by linville-x1.hq.tuxdriver.com (8.14.8/8.14.6) with ESMTP id s56KaCqJ015221; Fri, 6 Jun 2014 16:36:12 -0400 Received: (from linville@localhost) by linville-x1.hq.tuxdriver.com (8.14.8/8.14.8/Submit) id s56KaC3L015220; Fri, 6 Jun 2014 16:36:12 -0400 Date: Fri, 6 Jun 2014 16:36:11 -0400 From: "John W. Linville" To: Neil Horman Message-ID: <20140606203611.GB3208@tuxdriver.com> References: <1402082754-12921-1-git-send-email-linville@tuxdriver.com> <20140606203050.GB2543@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140606203050.GB2543@hmsreliant.think-freely.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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:44:54 -0000 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. John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready.