From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Mon, 6 Mar 2017 21:54:34 +0100 (CET) Received: by mail-pf0-f178.google.com with SMTP id j5so65157621pfb.2 for ; Mon, 06 Mar 2017 12:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=sWMeYJ0Y+YP4ZlHjur7sarniIGUc7IS784wrccwIns0=; b=MCwtAJFQI60XzalnF9Vjw2ma3gQDK9TuGToOgi4P+X10AWu5nEy5YWHeRgoMBCPukc oNcMBex0mhrMOGAcYloSa3c2diixASn8Z97ry48Q2STPnCEWbR7TCdrU5dFjSStZAKpl p/bEwCB4Vpa2oRuOwElH9aBQR+aZBbQj/kdQjn+3VFX4ZcyicnZIw5GXsdfHf1mxBYUS xW2FyxdCHCyntJJZz0YlZGOBl6FBewX7TaGl5iMZG7qExeqFHMKnpIYx7e2r128VHgGU 5gVzAHA8y2711Cv3FzN+4YfrkYrLo70aDoyLlSvGiCrZVQ6JYzGRR2JNDOQ9F0WXLFpz 0UKg== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=sWMeYJ0Y+YP4ZlHjur7sarniIGUc7IS784wrccwIns0=; b=GpiQ0jUdvPt19SBEGEWFHocKxk2WBr0E2igvclNX4XASiX1av4RACqlJYUSzqcOzLO IzmaXQkGRwBgGNCr4O7h7WhzDZivVSgw7OUk7T6DUq8UrtAF02SAoocUF2dbDkqze4yY k2cdKLCpURlwOE1ZLOG4oqYgpk1X75/dcelYl0pXxfsvHYuPfhndSr1DVnNrA3Y8PVx/ MCJ1uIV3pW9DTWIn8e5+XRm0bnaQzPfj7Y/FJuuffkWn4RP9HXOrOaXyxmRh5+dvB7bf 119ILwb0EJaU+qM+beBkFzX77Y5wkvoUD53A6EIju61VJ2qn3FefNL125oMhAtRI2CXS 9kLQ== X-Gm-Message-State: AMke39kWy2oIURIJKBVvvv2zLCMGj8xLqujjeRetpDM5uwrZEfW2iNdnAfV2QcBeKC31pA== X-Received: by 10.99.123.1 with SMTP id w1mr23031735pgc.118.1488833673712; Mon, 06 Mar 2017 12:54:33 -0800 (PST) Received: from xeon-e3 (204-195-18-65.wavecable.com. [204.195.18.65]) by smtp.gmail.com with ESMTPSA id x15sm22030255pgc.16.2017.03.06.12.54.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 Mar 2017 12:54:33 -0800 (PST) Date: Mon, 6 Mar 2017 12:54:25 -0800 From: Stephen Hemminger To: "Wiles, Keith" Cc: Thomas Monjalon , "Dumitrescu, Cristian" , DPDK , "jerin.jacob@caviumnetworks.com" , "balasubramanian.manoharan@cavium.com" , "hemant.agrawal@nxp.com" , "shreyansh.jain@nxp.com" , "Richardson, Bruce" Message-ID: <20170306125425.51b6455b@xeon-e3> In-Reply-To: <77383876-70CD-4F81-B179-B95ED52933D6@intel.com> 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 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: Mon, 06 Mar 2017 20:54:34 -0000 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.