From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 34CA22A6C for ; Thu, 22 Sep 2016 18:43:57 +0200 (CEST) Received: by mail-wm0-f54.google.com with SMTP id w84so263541798wmg.1 for ; Thu, 22 Sep 2016 09:43:57 -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=bLWsHwZ0MnC0XS6VmKMdmrwz9eM8lJbY6J7Qg7JX+H8=; b=xrRtHDFgFmMY8LC7qh/LBpSsXlaVzFrqmPxAj0ZJu5dItqB/qqq25HaKVer0YKS5KC v/SsYwmgLGCC65OZeqlUL64EnniuEXVt3oE5spbsYxKUb+3kHWKl8VGI3h/t0RklX/Kp NMhWNWpIo9OmeU/bqm2UN8OqTb4sj+BwpqVPDQ2Ft+Edw7VLLcANaMEa8oprSSzkOLiC eK+DTg9DpxXpV3Am4fxqQscLRv2uCZVLZIsyEOYy7dE/WTNQyEs7xV0secnB5bsDNT7F jzF9+uJCEQLjIeNrhRH1BBdXOpLi7sOKbhlXXBcI4ugbsVqHE1JOb3Acgm/nHknB+A4Y n7bg== 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=bLWsHwZ0MnC0XS6VmKMdmrwz9eM8lJbY6J7Qg7JX+H8=; b=lkzHV2KbRjYbL490hS397ugGoGsH+JSJb3R+o0XzX4fVqGm4qFs86fw5t9uK3S0re8 5DarGrtSNHXhXpcTtXU8ZqoQzZb9JduJGgPXc2gH9dWZIAD++SPp993B0eIDS+ZE8W9l 3ALeipsZ1DbT82TSN5LyWXvXJwQTPJsmW02yh82pabJljxLVNyHfrQBLROEzfiURirqR WXt0jO34pB3gCeX5RqMobVS0kCu408R5H3lHe3pldm6lT7pjcXkiwyMlnV3kwkTtLlWU Jeg5pARTpBEe6Zl2TIwSMxBMi7o9YUh2kW5gkSUekpJaYX1eN9YSD0YHhhrQSuumNJ+G l6+A== X-Gm-Message-State: AE9vXwNk8CkS0MJOJKvyCbv4A1hAldKX04X/ewxa8C0JksxodOKpw7Zy51yDy6htLwhdcYIL X-Received: by 10.194.98.205 with SMTP id ek13mr3206543wjb.158.1474562636977; Thu, 22 Sep 2016 09:43:56 -0700 (PDT) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id 188sm38593309wmo.1.2016.09.22.09.43.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Sep 2016 09:43:55 -0700 (PDT) From: Thomas Monjalon To: Yuanhan Liu Cc: Ciara Loftus , dev@dpdk.org Date: Thu, 22 Sep 2016 18:43:55 +0200 Message-ID: <3895093.sl81aq1Okb@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160922023650.GK23158@yliu-dev.sh.intel.com> References: <1473774463-26966-1-git-send-email-ciara.loftus@intel.com> <1673736.mOMazzh4h1@xps13> <20160922023650.GK23158@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: Thu, 22 Sep 2016 16:43:57 -0000 2016-09-22 10:36, Yuanhan Liu: > On Wed, Sep 21, 2016 at 03:07:51PM +0200, Thomas Monjalon wrote: > > 2016-09-18 16:27, Yuanhan Liu: > > > On Wed, Sep 14, 2016 at 10:35:53AM +0200, Thomas Monjalon wrote: > > > > 2016-09-14 15:21, Yuanhan Liu: > > > > > On Wed, Sep 14, 2016 at 09:10:48AM +0200, Thomas Monjalon wrote: > > > > > > 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. > > > > > > > > > > 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 to 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 very specific. > > It's not, instead, it's very generic. The "internal id" is actually the > public interface to vhost-user application, like "fd" to file APIs. > > Instead of introducing a few specific wrappers/APIs, I'd prefer to > introduce a generic one to get the handle, and let the application 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.