From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 91D58569F for ; Fri, 23 Sep 2016 10:43:22 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id b130so16910780wmc.0 for ; Fri, 23 Sep 2016 01:43:22 -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=7lefGlWcOsrlvD3rGVIq6xLpA6cmj+lvgpd9Ue9uhgA=; b=0h0uphTvTlRqAieTpVv1PpUCW9MJVq/w+sQSL1QF3C0IJ0fEQLuBrrwZa8GpGBz2SR 4H2/w5e/MwUAS5Ei/vFvox53xtOMcmBdI/2WaxO6irkIc7byaMqPff5ijnHToG0N0i8o 5uWDEuUkjygkT1qX48v8e1XjrZ1oPQc2NEGsKo60Toqrtfshy0g0Ckc8sWk/yap13CSc dKR/cA6nKqIxdTv++nSDY3iuqN0PKTowaaWgXBMJzHkA+bbg3tbzoMFRzz549ZR89TZw ImTflMaJvft9vUVvO99KSUjVkoMU6pCJRZVNVv6mp2g3LmAFws/8kMd6pyBwWz6Trbsc itlA== 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=7lefGlWcOsrlvD3rGVIq6xLpA6cmj+lvgpd9Ue9uhgA=; b=WvIyQSpHlAA2QaIqYx9sjRwJwlOwijWoU+zG3YnG8J2RGObAnZgyrV9gLSzRlkWhAr zXBKlQj/TK0u8o6jvTPNO5SklhTlx4zTAiaStsiGUIflmxEa1Tq3j8pYX45y1OY2bKpx L1E5Ej1jpBgsXMzgFJxj8dLqY9V1MKYZkmyprgXamvNdZE7CvIDgzNw6LekqeqcZHxs1 uCtarIj+tRM7YAkVvZBKblLUpb2qXBO1Rz0jRth3uLIZFRsaJm9ef8glTU0EKf3n0//3 JK/JTCGBAAZNj7chgmjRUpF1hbp4d9e7u6h+X/VzhFdLD+WsNRubg2cQy6y7oDcKZcqr XL1Q== X-Gm-Message-State: AE9vXwOEKws7MUTE76UyxZn13sOZ8TplJzRIrfXJYvjX2fY0pR9/3dJ8ljpUCg4amAi+Ka10 X-Received: by 10.194.45.232 with SMTP id q8mr5958812wjm.9.1474620202345; Fri, 23 Sep 2016 01:43:22 -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 ub8sm6055548wjc.39.2016.09.23.01.43.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Sep 2016 01:43:21 -0700 (PDT) From: Thomas Monjalon To: Yuanhan Liu Cc: Ciara Loftus , dev@dpdk.org, "Wiles, Keith" Date: Fri, 23 Sep 2016 10:43:20 +0200 Message-ID: <4215863.mCAoc6du0K@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160923042641.GP23158@yliu-dev.sh.intel.com> References: <1473774463-26966-1-git-send-email-ciara.loftus@intel.com> <3895093.sl81aq1Okb@xps13> <20160923042641.GP23158@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: Fri, 23 Sep 2016 08:43:22 -0000 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 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. > > Yes, that should work. But I just doubt what the "opaque pointer" could 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. > 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, because > 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.