From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH v3 1/2] ethdev: add capability control API
Date: Mon, 6 Mar 2017 12:54:25 -0800
Message-ID: <20170306125425.51b6455b@xeon-e3>
References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com>
 <12629083.yAQ7FffjSn@xps13>
 <3EB4FA525960D640B5BDFFD6A3D891265275B202@IRSMSX108.ger.corp.intel.com>
 <10140076.z0k8vql8dv@xps13>
 <77383876-70CD-4F81-B179-B95ED52933D6@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>, "Dumitrescu, Cristian"
 <cristian.dumitrescu@intel.com>, DPDK <dev@dpdk.org>,
 "jerin.jacob@caviumnetworks.com" <jerin.jacob@caviumnetworks.com>,
 "balasubramanian.manoharan@cavium.com"
 <balasubramanian.manoharan@cavium.com>, "hemant.agrawal@nxp.com"
 <hemant.agrawal@nxp.com>, "shreyansh.jain@nxp.com"
 <shreyansh.jain@nxp.com>, "Richardson, Bruce" <bruce.richardson@intel.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com
 [209.85.192.178]) by dpdk.org (Postfix) with ESMTP id 77EA7108A
 for <dev@dpdk.org>; Mon,  6 Mar 2017 21:54:34 +0100 (CET)
Received: by mail-pf0-f178.google.com with SMTP id j5so65157621pfb.2
 for <dev@dpdk.org>; Mon, 06 Mar 2017 12:54:34 -0800 (PST)
In-Reply-To: <77383876-70CD-4F81-B179-B95ED52933D6@intel.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Mon, 6 Mar 2017 20:41:27 +0000
"Wiles, Keith" <keith.wiles@intel.com> 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.