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 2FFDD3F9 for ; Fri, 6 Jun 2014 22:30:40 +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 1Wt0mp-0002Kb-BS; Fri, 06 Jun 2014 16:30:53 -0400 Date: Fri, 6 Jun 2014 16:30:50 -0400 From: Neil Horman To: "John W. Linville" Message-ID: <20140606203050.GB2543@hmsreliant.think-freely.org> References: <1402082754-12921-1-git-send-email-linville@tuxdriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1402082754-12921-1-git-send-email-linville@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:30:40 -0000 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. Neil