From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API Date: Wed, 11 Jan 2017 18:32:48 +0100 Message-ID: <20170111183248.38a27193@glumotte.dev.6wind.com> 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=US-ASCII Content-Transfer-Encoding: 7bit Cc: Tiwei Bie , "Ananyev, Konstantin" , Adrien Mazarguil , dev@dpdk.org, "Lu, Wenzhuo" , "Mcnamara, John" , olivier.matz@6wind.com, "Zhang, Helin" , "Dai, Wei" , "Wang, Xiao W" To: Thomas Monjalon Return-path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 27519689B for ; Wed, 11 Jan 2017 18:32:57 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id c85so163919011wmi.1 for ; Wed, 11 Jan 2017 09:32:57 -0800 (PST) In-Reply-To: <1542539.LCBRG7nZDl@xps13> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. Regards, Olivier