From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <linville@tuxdriver.com> Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 292BEAE99 for <dev@dpdk.org>; Mon, 14 Apr 2014 15:30:16 +0200 (CEST) Received: from uucp by smtp.tuxdriver.com with local-rmail (Exim 4.63) (envelope-from <linville@tuxdriver.com>) id 1WZgxh-0000uQ-PL; Mon, 14 Apr 2014 09:30:14 -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 s3EDKtBC028585; Mon, 14 Apr 2014 09:20:55 -0400 Received: (from linville@localhost) by linville-x1.hq.tuxdriver.com (8.14.8/8.14.8/Submit) id s3EDKsLI028584; Mon, 14 Apr 2014 09:20:54 -0400 Date: Mon, 14 Apr 2014 09:20:54 -0400 From: "John W. Linville" <linville@tuxdriver.com> To: Thomas Monjalon <thomas.monjalon@6wind.com> Message-ID: <20140414132053.GA27324@tuxdriver.com> References: <1460632.jOzC6OEr8u@xps13> <20140411174454.GE911@hmsreliant.think-freely.org> <59AF69C657FD0841A61C55336867B5B01A9FC02F@IRSMSX103.ger.corp.intel.com> <24514389.3vY1j6NNAg@x220> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24514389.3vY1j6NNAg@x220> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 14 Apr 2014 13:30:16 -0000 On Sat, Apr 12, 2014 at 08:05:22AM +0200, Thomas Monjalon wrote: > Hi Bruce, > > 11/04/2014 20:08, Richardson, Bruce : > > From: Neil Horman > > > On Fri, Apr 11, 2014 at 06:18:08PM +0200, Thomas Monjalon wrote: > > > > It seems that your patch is not removing > > > > rte_eth_ring_pair_create/rte_eth_ring_pair_attach so I'm not sure you > > > > can dynamically change the PMD in this case. > > > > > > Ew, I had missed those calls. Yes, those should be encapsulated as some > > > driver ops or some such. I'll look at that when I rebase. Regardless > > > however, I didn't mean to state that pmds could be switched while > > > running, only that the pmd to use could be specified at run time. > > > Though, you're correct, pmd_ring doesn't seem to hold in line with the > > > other pmds in their isolation. > > > > The ring PMD is probably best treated separately from the other PMDs as it's > > not really a device poll-mode driver. Instead, it's a general library that > > presents an API to make a ring, or set of rings, appear as a poll-mode > > driver ethdev. The EAL command to have one created at startup time was just > > an addon after-the-fact in case someone might find it useful :-). However, > > it's primary purpose was to allow applications to be written which could > > use physical NICs or rings interchangeably. For example, an app with > > multiple stages in a pipeline, where each stage just reads from an ethdev > > without caring if it's actually reading from a port or from packets sent > > from another lcore/function etc. Another example might be where an > > application wishes to sometimes loop packets back to itself, in this case > > it uses the C API to create an additional ring ethdev which it uses as > > output port for any packets it wants looped back - no special handling > > needed, everything is an ethdev to it on which it calls rx_burst or > > tx_burst. It's also likely that in future we will develop other libraries > > which wish to present their functionality via rx_burst/tx_burst functions > > i.e. as an ethdev. > > I think you are describing a vdev and you want to be able to instantiate this > vdev in your application code. Right? > So why not make a generic API to be able to instantiate a vdev? Treating vdevs as something inherently different from the hardware-backed PMDs continues to be the wrong approach. Ordinarily the whole point of having an abstraction that looks like a hardware device is so that applications can use either hardware or that abstraction without having to know the difference. Forcing applications to be vdev-aware defeats the whole purpose of wrapping those constructs inside a PMD in the first place. John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready.