From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 66D2F5A44 for ; Thu, 12 Jan 2017 03:40:10 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP; 11 Jan 2017 18:40:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,348,1477983600"; d="scan'208";a="1092998332" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga001.fm.intel.com with ESMTP; 11 Jan 2017 18:40:07 -0800 Date: Thu, 12 Jan 2017 10:42:19 +0800 From: Yuanhan Liu To: Olivier MATZ Cc: Thomas Monjalon , Tiwei Bie , "Ananyev, Konstantin" , Adrien Mazarguil , dev@dpdk.org, "Lu, Wenzhuo" , "Mcnamara, John" , "Zhang, Helin" , "Dai, Wei" , "Wang, Xiao W" Message-ID: <20170112024219.GG2402@yliu-dev.sh.intel.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20170111183248.38a27193@glumotte.dev.6wind.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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:40:10 -0000 On Wed, Jan 11, 2017 at 06:32:48PM +0100, Olivier MATZ wrote: > 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. JFYI, here is how the virtio handle the feature bits. It basically just divides it to two parts. >>From virtio 1.0 spec (2.2 Feature Bits): Feature bits are allocated as follows: - 0 to 23 Feature bits for the specific device type - 24 to 32 Feature bits reserved for extensions to the queue and feature negotiation mechanisms - 33 and above Feature bits reserved for future extensions. Note: For example, feature bit 0 for a network device (i.e. Device ID 1) indicates that the device supports checksumming of packets. --yliu