From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <yliu@fridaylinux.org>
Received: from mail-pf0-f193.google.com (mail-pf0-f193.google.com
[209.85.192.193]) by dpdk.org (Postfix) with ESMTP id 083CC235
for <dev@dpdk.org>; Sat, 8 Jul 2017 08:29:06 +0200 (CEST)
Received: by mail-pf0-f193.google.com with SMTP id c24so7228144pfe.1
for <dev@dpdk.org>; Fri, 07 Jul 2017 23:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=fridaylinux-org.20150623.gappssmtp.com; s=20150623;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-disposition:in-reply-to:user-agent;
bh=CibdPfzoPyCHr3COkiHNe2T0mgUJL6Qtmr1baO8ZXEY=;
b=OH6Wkk4XorLcEd1mJF/E+IIyBx67tx0/gmm8aENiR0BVB1fwdjyMerOI8PKxeYa36K
aqU9mDJIqNtrqQowgOM0EzGxiu7KUCecr734AEzODzo24+ABCnA8560a8WVLmYQ1f4Wb
dILdLsQfpFCx9ioYmx8/4Ilv0TeuOiFY4eYJOWL/XYT2LS3IwzX3rFQE93H7QWS8a7Db
8jQXvUKvzkhxW6PowzxeIXcKWUEuHIE9FaOJ4RP05yaJLSmq4hnJ/lxYZnGOEfXtjNtf
hSrd+dVhcny0fPNlEf2BDH76W3GOSCKTWVkDCoQEXRVv6siKMsY6EDZFeiFibpimHmAH
RYUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-disposition:in-reply-to:user-agent;
bh=CibdPfzoPyCHr3COkiHNe2T0mgUJL6Qtmr1baO8ZXEY=;
b=uZ0GJ2DiWfMbWITuIg9njZsLzbKevZw58OSC/Nwpj9DuKTTvvY50rDJhMPaAkBjgYi
4BXt4O0IitiRo31QVdnT1RkuxorGH/0KKg8xNTooYAc4AvKm5TBmcVrzU32880aa3LBI
X1wP+g4ouzcegMFbD8MsUtqgURLSZO2RTqLh3AHhT5uaKOeZd6x2A8hJHrixmmJfxwyx
A69fELGVJtWbL2eRWnT1c0S4VTfXsZxSahPqMnH/xy8M8MU5LbYTQxmHkbGYPnkZLAzS
9TBQ6FvZBH3NZLWggPFT4EcksUHZnS++IWTsJn8/7NKF86PPtVBgyQ51z68JrZS3AkSB
hCVQ==
X-Gm-Message-State: AIVw1127rv+vjQD/zxhzbjXD9U5otTYoSSd9oGjDaE89eJvzujLnZ2GI
Un/HoxURQsNSgMwW
X-Received: by 10.84.231.9 with SMTP id f9mr7055693plk.257.1499495346216;
Fri, 07 Jul 2017 23:29:06 -0700 (PDT)
Received: from yliu-home ([45.63.61.64])
by smtp.gmail.com with ESMTPSA id w190sm10783538pgb.30.2017.07.07.23.29.03
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Fri, 07 Jul 2017 23:29:04 -0700 (PDT)
Date: Sat, 8 Jul 2017 14:28:59 +0800
From: Yuanhan Liu <yliu@fridaylinux.org>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org, Stephen Hemminger <stephen@networkplumber.org>,
Bruce Richardson <bruce.richardson@intel.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
Thomas Monjalon <thomas@monjalon.net>
Message-ID: <20170708062859.GB11626@yliu-home>
References: <20170704161337.45926-1-ferruh.yigit@intel.com>
<20170704161337.45926-21-ferruh.yigit@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170704161337.45926-21-ferruh.yigit@intel.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Subject: Re: [dpdk-dev] [PATCH v10 20/20] ethdev: add control interface
support
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Jul 2017 06:29:07 -0000
On Tue, Jul 04, 2017 at 05:13:37PM +0100, Ferruh Yigit wrote:
> @@ -157,8 +164,12 @@ rte_eth_dev_pci_generic_probe(struct rte_pci_device *pci_dev,
>
> RTE_FUNC_PTR_OR_ERR_RET(*dev_init, -EINVAL);
> ret = dev_init(eth_dev);
> - if (ret)
> + if (ret) {
> rte_eth_dev_pci_release(eth_dev);
> + return ret;
> + }
> +
> + rte_eth_control_interface_create(eth_dev->data->port_id);
Hi,
So you are creating a virtual kernel interface for each PCI port. What
about the VDEVs? If you plan to create one for each port, why not create
it at the stage while allocating the eth device, or at the stage while
starting the port if the former is too earlier?
Another thing comes to my mind is have you tried it with multi-process
model? Looks like it will create the control interface twice? Or it will
just be failed since the interface already exists?
I also have few questions regarding the whole design. So seems that the
ctrl_if only exports two APIs and they all will be only used in the EAL
layer. Thus, one question is did you plan to let APP use them? Judging
EAL already calls them automatically, I don't think it makes sense to
let the APP call it again. That being said, what's the point of the making
it be an lib? Why not just put it under EAL or somewhere else, and let
EAL invoke it as normal helper functions (instead of by public APIs)?
I will avoid adding a new lib if possible. Otherwise, it increases the
chance of ABI/API breakage is needed in future for extensions.
The same question goes to the ethtool lib. Since your solution can work
well with the well-known ethtool, which is also way more widely available
than the DPDK ethtool app, what's the point of keeping the ethtool app
then? Like above, I also don't think those APIs are meant for APPs (or
are they?). Thus, with the ethtool app removed, we then could again avoid
introducing a new lib.
--yliu