From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Subject: Re: [PATCH v5 3/8] ethdev: reserve capability flags for
 PMD-specific API
Date: Thu, 12 Jan 2017 10:42:19 +0800
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
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>,
 Tiwei Bie <tiwei.bie@intel.com>,
 "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>,
 "Zhang, Helin" <helin.zhang@intel.com>, "Dai, Wei" <wei.dai@intel.com>,
 "Wang, Xiao W" <xiao.w.wang@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
 by dpdk.org (Postfix) with ESMTP id 66D2F5A44
 for <dev@dpdk.org>; Thu, 12 Jan 2017 03:40:10 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <20170111183248.38a27193@glumotte.dev.6wind.com>
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 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