From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 96D4B8D3B for ; Wed, 14 Sep 2016 09:10:50 +0200 (CEST) Received: by mail-wm0-f48.google.com with SMTP id i130so31842744wmf.0 for ; Wed, 14 Sep 2016 00:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=rs5at9SqUJkNUluJi+mghRQS+6rdQxY422bErPisywc=; b=OCzpnQCK7hVE0GQsr5EKhTrrD3PIjLifSy+l0yXceITjXmpuuxYEJEvndUR8sg3x5q xaXcY9OaJ9uN9vKj8IM+0n/aWt2Kqr/+4PGxRZRnFFnSfztQuIm3FCnEeGT30mwIMdM2 L8SQszpJAIm8dq8B5iZCUAv/zJBx6KuO8j1H4hHf/0lzhTUH3xH82+DmgflKrIO83w4Z WYUvn+7KdzfVyw/jwia3Eeml4wAS+sjiNIw6t9RrLHcljt8y9e5/kaG6xEgD8sX1TZcb sX7R14ayN41jV1p2h1OrBbSDOHWEXzN9p6ztzr1w92mEzRb19RYutmtNRF/8V07OFr8K Pu9w== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=rs5at9SqUJkNUluJi+mghRQS+6rdQxY422bErPisywc=; b=YFG/70O6YVWy9UvNUiI1lbHS/qlT8Ril4XSaqr2rmvJPLJYAharVTDoO2svpyhQQeb zYfKEBNSlZ3s1+AgtCM+GCrgceyDz+f280OYUCQyru7N2OTfmjbqRA9KJpjPxGdm2l4A aGTSetBDsWhR4/q/LExrROrCpuP4V1jOXqhGnqPhk+Eh1oz96svhs/6W7U3FF4D6ujAq nhtQtUbbwNQ+danE0tjGDuyjj4Nabgg2zwrFGuHC9dCEnWwh/fL4iKmVv3Cwkzfh0Ioo 76nJLhaKQBLiuxuhzpoGZuXEHRoGyaxeKJHMSA6F73EQYePhZpgYcmfdVc3YTJopL5Uf nbNg== X-Gm-Message-State: AE9vXwMcQc8pcguwcNuCuR/44mvI/tYpCSIGdmFX3MUaiuZmUpW+nDUJxV74k2syvrnamzB2 X-Received: by 10.194.43.98 with SMTP id v2mr1152881wjl.46.1473837050359; Wed, 14 Sep 2016 00:10:50 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id e12sm9114758wmg.17.2016.09.14.00.10.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Sep 2016 00:10:49 -0700 (PDT) From: Thomas Monjalon To: Yuanhan Liu , Ciara Loftus Cc: dev@dpdk.org Date: Wed, 14 Sep 2016 09:10:48 +0200 Message-ID: <1934917.EiaaJTRqAq@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160914044329.GX23158@yliu-dev.sh.intel.com> References: <1473774463-26966-1-git-send-email-ciara.loftus@intel.com> <28342659.xFrdpVFeBf@xps13> <20160914044329.GX23158@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Wed, 14 Sep 2016 07:10:50 -0000 2016-09-14 12:43, Yuanhan Liu: > On Tue, Sep 13, 2016 at 05:10:09PM +0200, Thomas Monjalon wrote: > > 2016-09-13 14:47, Ciara Loftus: > > > In some cases when using the vHost PMD, certain vHost library functions > > > may still need to be accessed. One such example is the > > > rte_vhost_get_queue_num function which returns the number of virtqueues > > > reported by the guest - information which is not exposed by the PMD. > > > > > > This commit introduces a new rte_eth_vhost function that returns the > > > 'vid' associated with a given port id. This allows the PMD user to call > > > vHost library functions which require the 'vid' value. > > > > I think we should not add any API to the PMDs. > > In general, I agree with you. > > > Maybe you are looking for a generic API in ethdev. > > But maybe it's a bit hard to define a "right" generic API here. For this > case, the generic API I can think of could be: > > - an API to get queue num, like rte_eth_get_queue_enabled_num > I barely know NIC pmd drivers, but I doubt it's useful/meaningful for them. > > - an API to get a PMD driver private (or specific) data. > For vhost-pmd, it's vid. Again, I don't know what it could be for other nic > drivers. > > This one may be a better option here, because it expose a key field to > the application, vid, with which the application can invoke more vhost > APIs. And apparently, it's not feasible to try to define a generic API > for some (if not each) vhost APIs. 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.