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 5414758E0 for ; Mon, 19 May 2014 15:40:53 +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 1WmNoJ-0001bL-K1; Mon, 19 May 2014 09:41:01 -0400 Date: Mon, 19 May 2014 09:40:58 -0400 From: Neil Horman To: "Richardson, Bruce" Message-ID: <20140519134058.GB2215@hmsreliant.think-freely.org> References: <1400264114-28455-1-git-send-email-bruce.richardson@intel.com> <20140516185417.GC5432@hmsreliant.think-freely.org> <59AF69C657FD0841A61C55336867B5B01AA1B2C5@IRSMSX103.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59AF69C657FD0841A61C55336867B5B01AA1B2C5@IRSMSX103.ger.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 0/3] ring: provide rte_ring_as_ethdev API 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: Mon, 19 May 2014 13:40:53 -0000 On Mon, May 19, 2014 at 10:59:18AM +0000, Richardson, Bruce wrote: > > > > -----Original Message----- > > From: Neil Horman [mailto:nhorman@tuxdriver.com] > > Sent: Friday, May 16, 2014 7:54 PM > > To: Richardson, Bruce > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/3] ring: provide rte_ring_as_ethdev API > > > > On Fri, May 16, 2014 at 07:15:11PM +0100, Bruce Richardson wrote: > > > > > NAK, I don't think this makes sense. If you want to encapsulate a ring pair as > > an ethdev, then write a pmd that does so. That will give you a standardized > > ethdev that you can create using the existing --vdev librte_eal command line > > options without having to widen your API surface, or having to write > > applications that specifically know about the fact that your ethdev is composed > > of rings under the covers. > > > > The objective is not to "encapsulate a ring pair", but instead allow a ring to be "type-cast" to an ethdev for the purposes of rx and tx. Thats semantics. Whatever you want to call it, you're goal is to treat a ring pair like an ethernet interface. You already have a mechanism to do that, librte_pmd_ring. > If this is provided, we can provide standard functions which work to take packets in using rx_burst and which send packets out after processing using tx_burst. The same code can then be used unmodified without worrying about whether the packets come from/to a NIC or from another core (via ring). Again, you can already do this, librte_pmd_ring. You're re-inventing the wheel. If what you want is the ability to dynamically take a ring that you've created and use it interchangeably as a ring and an ethernet device, I would suggest one of the following: 1) Create a loopback PMD that registers a port, where anything transmitted to it is immediately recieved on it again. This allows you to reuse the existing rte_eth_* api entirely to accomplish what you need 2) Create a tap device library and PMD, akin to the linux Tun/Tap device driver. This is some additional work of course, and still expands the api, but does so in a controlled and generic manner, useful to other applications. By that I mean that other data sources besides librte_ring can be used to feed data into the network stack (pcap files or port mirroring applications, etc). Either way, what you have right now is doing little more than solving a generic problem only for one data source, in a way that unnecessecarily expands the API surface. Neil