From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API Date: Mon, 09 Jan 2017 12:26:53 +0100 Message-ID: <1542539.LCBRG7nZDl@xps13> References: <2601191342CEEE43887BDE71AB9772583F0FEE0C@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F10241C@irsmsx105.ger.corp.intel.com> <20170109035736.GA11691@debian> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, "Lu, Wenzhuo" , "Mcnamara, John" , olivier.matz@6wind.com, "Zhang, Helin" , "Dai, Wei" , "Wang, Xiao W" To: Tiwei Bie , "Ananyev, Konstantin" , Adrien Mazarguil Return-path: Received: from mail-wj0-f169.google.com (mail-wj0-f169.google.com [209.85.210.169]) by dpdk.org (Postfix) with ESMTP id 379FA326C for ; Mon, 9 Jan 2017 12:26:55 +0100 (CET) Received: by mail-wj0-f169.google.com with SMTP id i20so63480235wjn.2 for ; Mon, 09 Jan 2017 03:26:55 -0800 (PST) In-Reply-To: <20170109035736.GA11691@debian> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2017-01-09 11:57, Tiwei Bie: > On Sun, Jan 08, 2017 at 08:39:55PM +0800, Ananyev, Konstantin wrote: > > > Well my first reply to this thread was asking why isn't the whole API global > > > from the start then? > > > > That's good question, and my preference would always be to have the > > API to configure this feature as generic one. > > I guess the main reason why it is not right now we don't reach an agreement > > how this API should look like: > > http://dpdk.org/ml/archives/dev/2016-September/047810.html > > But I'll leave it to the author to provide the real reason here. > > Yes, currently this work just provided a thin layer over 82599's > hardware MACsec offload support to allow users configure 82599's > MACsec offload engine. The current API may be too specific and may > need a rework to be used with other NICs. I think it is a really good approach to start such API privately in a driver. It will give us more time and experience to design a proper generic API. Regarding the mbuf flag, it looks straight-forward, and as it is IEEE standardized, I do not see any objection to add it now. However, I will wait for the approval of Olivier - as maintainer of mbuf.