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 14E81AF8A for ; Mon, 14 Apr 2014 16:15:19 +0200 (CEST) Received: from uucp by smtp.tuxdriver.com with local-rmail (Exim 4.63) (envelope-from ) id 1WZhfI-0001Cy-U8; Mon, 14 Apr 2014 10:15:16 -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 s3EEAVkb030216; Mon, 14 Apr 2014 10:10:32 -0400 Received: (from linville@localhost) by linville-x1.hq.tuxdriver.com (8.14.8/8.14.8/Submit) id s3EEAVE1030215; Mon, 14 Apr 2014 10:10:31 -0400 Date: Mon, 14 Apr 2014 10:10:31 -0400 From: "John W. Linville" To: Thomas Monjalon Message-ID: <20140414141030.GB27324@tuxdriver.com> References: <1460632.jOzC6OEr8u@xps13> <24514389.3vY1j6NNAg@x220> <20140414132053.GA27324@tuxdriver.com> <4737854.PZKb5HIIVb@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4737854.PZKb5HIIVb@xps13> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:15:19 -0000 On Mon, Apr 14, 2014 at 03:45:31PM +0200, Thomas Monjalon wrote: > Hi John, > > 2014-04-14 09:20, John W. Linville: > > On Sat, Apr 12, 2014 at 08:05:22AM +0200, Thomas Monjalon wrote: > > > 11/04/2014 20:08, Richardson, Bruce : > > > > 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. > > I think there is a misunderstanding here. So it seems. > From the user's point of view, it must be possible to create some virtual > devices instead of using real ones. That's --vdev option. Then the device is > handled as any other one thanks to its PMD. Except that it isn't, or at least it wasn't -- hence my patch to make rte_pmd_init_all initialize _all_ PMDs rather than just the hardware ones. I hope that will be remedied once all the dust settles with the patchsets currently in flight. > From the application's point of view, all devices must be handled with the > same API (ethdev). But sometimes, application wants to force creation of > virtual devices like pmd_ring. So we need an API for this creation part. Then > the device is still handled with the generic ethdev API. > > Do you still see any problem with this approach? > > Hope it's clear. To me, it seems like a strange thing to do. But I am ambivalent about such an API if others want it. My main concern on this topic is that applications can be blissfully unaware of whether they are using virtual devices or not. If someone actually wants to know about that, then feel free to sell them the rope. John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready.