From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yuanhan Liu Subject: Re: [PATCH v10 20/20] ethdev: add control interface support Date: Sat, 8 Jul 2017 14:28:59 +0800 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 Cc: dev@dpdk.org, Stephen Hemminger , Bruce Richardson , Anatoly Burakov , Thomas Monjalon To: Ferruh Yigit 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) Content-Disposition: inline In-Reply-To: <20170704161337.45926-21-ferruh.yigit@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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