From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tiwei Bie <tiwei.bie@intel.com>
Subject: Re: [PATCH v5 3/8] ethdev: reserve capability flags for
 PMD-specific API
Date: Tue, 10 Jan 2017 10:08:23 +0800
Message-ID: <20170110020823.GE9500@debian>
References: <2601191342CEEE43887BDE71AB9772583F0FEE0C@irsmsx105.ger.corp.intel.com>
 <2601191342CEEE43887BDE71AB9772583F10241C@irsmsx105.ger.corp.intel.com>
 <20170109035736.GA11691@debian> <1542539.LCBRG7nZDl@xps13>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 Adrien Mazarguil <adrien.mazarguil@6wind.com>, dev@dpdk.org,
 "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
 "Mcnamara, John" <john.mcnamara@intel.com>, olivier.matz@6wind.com,
 "Zhang, Helin" <helin.zhang@intel.com>, "Dai, Wei" <wei.dai@intel.com>,
 "Wang, Xiao W" <xiao.w.wang@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id CAE4F152A
 for <dev@dpdk.org>; Tue, 10 Jan 2017 03:09:24 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <1542539.LCBRG7nZDl@xps13>
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, Jan 09, 2017 at 12:26:53PM +0100, Thomas Monjalon wrote:
> 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.
> 

I see. Thank you very much for your comments! :-)

Best regards,
Tiwei Bie