From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com [209.85.128.176]) by dpdk.org (Postfix) with ESMTP id 11D6D914 for ; Tue, 7 Mar 2017 13:56:57 +0100 (CET) Received: by mail-wr0-f176.google.com with SMTP id u48so725768wrc.0 for ; Tue, 07 Mar 2017 04:56:57 -0800 (PST) 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=ByeFKfz47e21wBIDpP+ulClcjGt0hrX9CEW64pmomFY=; b=00ejP3kwGl52NKOmsjB3KEzxUIBX6SXenycSdALsceNPS6p3ELtHfbwMnzGquCHtZc 3E01W61vxnJW/LHFkGEAnU/szA+yCob1IopXtEKe2RZLzR3tw6Y8YgMBcjpcdyKuke89 09yml6Hxtx+eQx9h+Bv+e/Cqj49+QqeJHkwDF0OY/LUI1D9kcVx2jCEZ8F1HRDcXi/tS kEyf8NVip61arHKvN6mPJjh2S+LsxFO7fKD38dw1kE2TWWQr/YlNl+fmrcc7M9zT0RK4 7jKnxA/KGXCWvMShvqW7Y7Z80787u7FyCCGTdYrbZeVvq+xjae6pcfTDcg4hZhOXQgsX N5dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=ByeFKfz47e21wBIDpP+ulClcjGt0hrX9CEW64pmomFY=; b=VTfaLMu9jMd80EcOWrxTHAHs9U/rWrOVnT+npwJRGmEXT8xRBplmhjlKKQIV7CKUmH OkgvJQydTalrkg4AAhm4hxM13OL52cj2hEmyS3FLf7nwdKDkH8efs5UPhZpIf+FM7dS3 3MBRyxshVy6vL1xn/u4TQWFDRAzk560hS5K4in75rAlxbalT04YJW47uGIJlq8LHUU3y pN9P12oK6xRziq2NG/ESU19NvG7i/yjquTCDUF7OtkIvUYZnf2lZzzzlx7NLvc9vM9ew 45hEz/BsKrVhLGIKQhPKNXy3Ih+E+6VievDWgGSjDHNYC/1QdfNxMMGORrgMgHu2XYBQ Hs9A== X-Gm-Message-State: AMke39kdZz6K0lSD9vybXh64jFpjKI7Zyfy+3WdE8dQ1NjqBxEyA7f/G1AQ40iGi9pPK/tmQ X-Received: by 10.223.136.66 with SMTP id e2mr139991wre.14.1488891416787; Tue, 07 Mar 2017 04:56:56 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id m139sm21166471wma.2.2017.03.07.04.56.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 04:56:55 -0800 (PST) From: Thomas Monjalon To: "Dumitrescu, Cristian" Cc: Stephen Hemminger , "Wiles, Keith" , dev@dpdk.org, "jerin.jacob@caviumnetworks.com" , "balasubramanian.manoharan@cavium.com" , "hemant.agrawal@nxp.com" , "shreyansh.jain@nxp.com" , "Richardson, Bruce" Date: Tue, 07 Mar 2017 13:56:54 +0100 Message-ID: <6779658.J26ZzuZ3zA@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891265275B5BA@IRSMSX108.ger.corp.intel.com> References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com> <20170306125425.51b6455b@xeon-e3> <3EB4FA525960D640B5BDFFD6A3D891265275B5BA@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 1/2] ethdev: add capability control API 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: Tue, 07 Mar 2017 12:56:57 -0000 2017-03-07 10:14, Dumitrescu, Cristian: > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > On Mon, 6 Mar 2017 20:41:27 +0000 > > "Wiles, Keith" wrote: > > > > > Being able to add features without having to change DPDK maybe a strong > > feature for companies that have special needs for its application. They just > > need to add a rte_eth_capability enum in a range that they want to control > > (which does not mean they need to change the above structure) and they > > can provide private features to the application especially if they are very > > specific features to some HW. I do not like private features, but I also do not > > want to stick just any old API in DPDK for any given special feature. > > > > > > I understand why you make that argument, but in practice it doesn't work > > that way. > > When new features get added to DPDK, then the application must request > > those features through configration and other > > API's. Therefore building everything into eth_dev doesn't seem to be > > helpful. > > Stephen, I think we are all aligned here. Question is: do you want the application to discover the supported capabilities through a standard API or do you want each capability to provide its own specific discovery mechanism (if any)? This patch proposes a standard API. Just a precision: A function with a void* parameter is not a fully defined API. We still need to know how to interpret the void* in each case.