From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id A81D12C6D for ; Thu, 12 Jan 2017 03:09:30 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP; 11 Jan 2017 18:09:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,347,1477983600"; d="scan'208";a="921561165" Received: from debian.sh.intel.com (HELO debian) ([10.239.67.170]) by orsmga003.jf.intel.com with ESMTP; 11 Jan 2017 18:09:27 -0800 Date: Thu, 12 Jan 2017 10:08:26 +0800 From: Tiwei Bie To: Olivier MATZ Cc: Thomas Monjalon , "Ananyev, Konstantin" , Adrien Mazarguil , dev@dpdk.org, "Lu, Wenzhuo" , "Mcnamara, John" , "Zhang, Helin" , "Dai, Wei" , "Wang, Xiao W" Message-ID: <20170112020826.GA24682@debian> References: <2601191342CEEE43887BDE71AB9772583F0FEE0C@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F10241C@irsmsx105.ger.corp.intel.com> <20170109035736.GA11691@debian> <1542539.LCBRG7nZDl@xps13> <20170111183248.38a27193@glumotte.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170111183248.38a27193@glumotte.dev.6wind.com> User-Agent: Mutt/1.7.2 (2016-11-26) Subject: Re: [dpdk-dev] [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific 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: Thu, 12 Jan 2017 02:09:31 -0000 On Wed, Jan 11, 2017 at 06:32:48PM +0100, Olivier MATZ wrote: > Hi Tiwei, Hi Thomas, > > On Mon, 09 Jan 2017 12:26:53 +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. > > > > Generally speaking, we have to be careful when introducing new mbuf > flags, since we don't have so much of them (~25 remaining out of 64, > which mean we may run out of them in 3-4 years). > > In this particular case, despite the flag is added for an ixgbe-specific > API, when MACsec will be implemented on another PMD, the exact same > flag would also be needed. That's the same for the ethdev capability > flag. Moreover, as Thomas stated, it's a standardized protocol so it's > legitimate to have it included in rte_mbuf.h. > > For me, having PMD-specific APIs for a new feature is not a problem, > but I think we should try to have a generic API as soon as the feature > is supported by several PMDs. > Sure! Thank you very much! Best regards, Tiwei Bie