From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Sat, 8 Jul 2017 08:29:06 +0200 (CEST) Received: by mail-pf0-f193.google.com with SMTP id c24so7228144pfe.1 for ; 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 To: Ferruh Yigit Cc: dev@dpdk.org, Stephen Hemminger , Bruce Richardson , Anatoly Burakov , Thomas Monjalon 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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