From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by dpdk.org (Postfix) with ESMTP id 9A0E6AE9C for ; Mon, 14 Apr 2014 15:45:32 +0200 (CEST) Received: by mail-we0-f170.google.com with SMTP id w61so8164298wes.29 for ; Mon, 14 Apr 2014 06:45:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=dt2uSgU8kvh27EmI82MvvbK+v1Mrn+dYP1lI4MObIBs=; b=CkTvFGbz1KvQ02b/Ryt3ecOaU9IqELqKmO/79vzV77Y+Yq6vPfZRHSiasb0+emi1zX VAmBJWgYl5OQcsvvk4MHPVAeLQQ8sGXIS3Lap83iWoevDu6fRxqYkPJX1Pw0A+EHsTMq ymVL9B86GhJtqVb9Z/A6CKvfPHxuG3rbqLzghG8dYJTsqTp4XYaIMvMklKTVRDfvZwpu fVGbAjKll5TW0C7x/DaqQ3LMSyOaaec95cv4IhYPuKw6WX89fGVt9HPk6bM5ChsVLIrW xqnzoQdtviLT0lBqZrmwiVhna6KvkIn52iy3kUv73Zml8qBn2GJPoCZZOWU22tqfh+Sg ZGMg== X-Gm-Message-State: ALoCoQmTpD7I+h476NzwsT0oDD+UlezvVNa1B1ItZuoTASQfvTTsycj0j+fndWCFNH9T2gfwpifQ X-Received: by 10.194.161.168 with SMTP id xt8mr33184751wjb.35.1397483132388; Mon, 14 Apr 2014 06:45:32 -0700 (PDT) Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id hp5sm25129715wjb.0.2014.04.14.06.45.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Apr 2014 06:45:31 -0700 (PDT) From: Thomas Monjalon To: "John W. Linville" Date: Mon, 14 Apr 2014 15:45:31 +0200 Message-ID: <4737854.PZKb5HIIVb@xps13> Organization: 6WIND User-Agent: KMail/4.12.3 (Linux/3.13.7-1-ARCH; KDE/4.12.3; x86_64; ; ) In-Reply-To: <20140414132053.GA27324@tuxdriver.com> References: <1460632.jOzC6OEr8u@xps13> <24514389.3vY1j6NNAg@x220> <20140414132053.GA27324@tuxdriver.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:45:32 -0000 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? Hope it's clear. -- Thomas