From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id A67FA5939 for ; Fri, 23 Sep 2016 11:26:26 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP; 23 Sep 2016 02:26:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,381,1470726000"; d="scan'208";a="764792165" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by FMSMGA003.fm.intel.com with ESMTP; 23 Sep 2016 02:26:25 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.209]) by IRSMSX102.ger.corp.intel.com ([169.254.2.248]) with mapi id 14.03.0248.002; Fri, 23 Sep 2016 10:26:24 +0100 From: "Loftus, Ciara" To: Yuanhan Liu , Thomas Monjalon CC: "dev@dpdk.org" , "Wiles, Keith" Thread-Topic: [dpdk-dev] [PATCH] net/vhost: Add function to retreive the 'vid' for a given port id Thread-Index: AQHSDkJ/w+XfGtx18U+v08bNaBsZUqB4gPQAgAAC7wCAABTWgIAGRu4AgAUFYYCAAOIHAIAA7KyAgADEWYCAAEe1AIAACSyAgAAQ42A= Date: Fri, 23 Sep 2016 09:26:23 +0000 Message-ID: <74F120C019F4A64C9B78E802F6AD4CC24F95A8BB@IRSMSX106.ger.corp.intel.com> References: <1473774463-26966-1-git-send-email-ciara.loftus@intel.com> <3895093.sl81aq1Okb@xps13> <20160923042641.GP23158@yliu-dev.sh.intel.com> <4215863.mCAoc6du0K@xps13> <20160923091609.GC23158@yliu-dev.sh.intel.com> In-Reply-To: <20160923091609.GC23158@yliu-dev.sh.intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzVhZmY2Y2QtOTg4OS00YjhlLTg0MTktNmM3NWE3NTE1ZmYxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InMxckVGZ2ZuNkVoSnNBMHQ0SkJxa0ZucStGaU82dlB4ZjhUaGx2c3JwSEU9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/vhost: Add function to retreive the 'vid' for a given port id 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: Fri, 23 Sep 2016 09:26:27 -0000 > On Fri, Sep 23, 2016 at 10:43:20AM +0200, Thomas Monjalon wrote: > > 2016-09-23 12:26, Yuanhan Liu: > > > On Thu, Sep 22, 2016 at 06:43:55PM +0200, Thomas Monjalon wrote: > > > > > > > > > > There could be a similar need in other PMD. > > > > > > > > > > If we can get an opaque identifier of the device which = is not > the port id, > > > > > > > > > > we could call some specific functions of the driver not > implemented in > > > > > > > > > > the generic ethdev API. > > > > > > > > > > > > > > > > > > That means you have to add/export the PMD API first. Isn'= t it > against what > > > > > > > > > you are proposing -- "I think we should not add any API t= o the > PMDs" ;) > > > > > > > > > > > > > > > > Yes you are totally right :) > > > > > > > > Except that in vhost case, we would not have any API in the > PMD. > > > > > > > > But it would allow to have some specific API in other PMDs = for > the features > > > > > > > > which do not fit in a generic API. > > > > > > > > > > > > > > So, does that mean you are okay with this patch now? I mean, > okay to introduce > > > > > > > a vhost PMD API? > > > > > > > > > > > > It means I would be in favor of introducing API in drivers for = very > specific > > > > > > features. > > > > > > In this case, I am not sure that retrieving an internal id is v= ery > specific. > > > > > > > > > > It's not, instead, it's very generic. The "internal id" is actual= ly the > > > > > public interface to vhost-user application, like "fd" to file API= s. > > > > > > > > > > Instead of introducing a few specific wrappers/APIs, I'd prefer t= o > > > > > introduce a generic one to get the handle, and let the applicatio= n to > > > > > call other vhost APIs. > > > > > > > > Yes it makes sense. > > > > I was thinking of introducing a function to get an internal id from > ethdev, > > > > in order to use it with any driver or underlying library. > > > > But it would be an opaque pointer and you need an int. > > > > Note that we can cast an int into a pointer, so I am not sure what = is > best. > > > > > > Yes, that should work. But I just doubt what the "opaque pointer" cou= ld > be > > > for other PMD drivers, and what the application could do with it. For= a > > > typical nic PMD driver, I can think of nothing is valuable to export = to > > > user applications. > > > > > > But maybe it's valuable to other virtual PMD drives as well, like the= TAP > > > pmd from Keith? > > > > > > If so, we may go that way. > > > > I would like to have more opinions/votes before proceeding. >=20 > Sure, fair enough. There is no rush. My hope would be have this, or at least some way to access rte_vhost_get_qu= eue_num(vid) from the PMD in 16.11. We can't integrate the PMD into OVS unt= il we achieve this. Is this likely at this stage given the uncertainty arou= nd the API? Thanks, Ciara >=20 > > > Another thought is that, it may be a bit weird to me to introduce an = API > > > to get an opaque pointer. I mean, it's a bit hard to document it, bec= ause > > > it has different meaning for different drivers. Should we list all of > > > them then? > > > > I think it can be documented in API using this handler how it can > > be retrieved. In your case, the vhost lib can explain that the vid > > is retrieved from the PMD with this generic ethdev function. >=20 > Okay. >=20 > --yliu