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 CE70DAF81 for ; Mon, 14 Apr 2014 15:54:22 +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 1WZhKz-00014n-Ci; Mon, 14 Apr 2014 09:54:21 -0400 Date: Mon, 14 Apr 2014 09:54:16 -0400 From: Neil Horman To: Thomas Monjalon Message-ID: <20140414135416.GA17006@hmsreliant.think-freely.org> 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) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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 13:54:23 -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. > 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. > 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? > The need to pass virtual device configuration information into a given vdev pmd is acceptible I think. The need to have separate initalization paths inside the libraries for dpdk is not. I think thats what needs to get fixed here. Theres no reason that physical devices can't use the same init path that virtual devices do, and just have their name and params arguments forced to NULL. Its creates a common path that makes coding devices easier. Neil > Hope it's clear. > -- > Thomas >