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 BDFE63777 for ; Wed, 4 Jan 2017 15:44:47 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga104.jf.intel.com with ESMTP; 04 Jan 2017 06:44:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,459,1477983600"; d="scan'208";a="209572630" Received: from dpdk19.sh.intel.com (HELO dpdk19) ([10.239.129.113]) by fmsmga004.fm.intel.com with ESMTP; 04 Jan 2017 06:44:43 -0800 Date: Wed, 4 Jan 2017 22:39:24 +0800 From: Tiwei Bie To: "Ananyev, Konstantin" Cc: "dev@dpdk.org" , "adrien.mazarguil@6wind.com" , "Lu, Wenzhuo" , "Mcnamara, John" , "olivier.matz@6wind.com" , "thomas.monjalon@6wind.com" , "Zhang, Helin" , "Dai, Wei" , "Wang, Xiao W" Message-ID: <20170104143923.GA57552@dpdk19> References: <1482939691-34855-1-git-send-email-tiwei.bie@intel.com> <1483514502-32841-1-git-send-email-tiwei.bie@intel.com> <1483514502-32841-4-git-send-email-tiwei.bie@intel.com> <2601191342CEEE43887BDE71AB9772583F0FEE0C@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0FEE0C@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Wed, 04 Jan 2017 14:44:48 -0000 On Wed, Jan 04, 2017 at 10:21:08PM +0800, Ananyev, Konstantin wrote: > Hi Twei, > > > -----Original Message----- > > From: Bie, Tiwei > > Sent: Wednesday, January 4, 2017 7:22 AM > > To: dev@dpdk.org > > Cc: adrien.mazarguil@6wind.com; Lu, Wenzhuo ; Mcnamara, John ; > > olivier.matz@6wind.com; thomas.monjalon@6wind.com; Ananyev, Konstantin ; Zhang, Helin > > ; Dai, Wei ; Wang, Xiao W > > Subject: [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API > > > > Reserve a Tx capability flag and a Rx capability flag, that can be > > used by PMD to define its own capability flags when implementing the > > PMD-specific API. > > > > Suggested-by: Adrien Mazarguil > > Signed-off-by: Tiwei Bie > > Acked-by: Wenzhuo Lu > > --- > > lib/librte_ether/rte_ethdev.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h > > index d465825..8800b39 100644 > > --- a/lib/librte_ether/rte_ethdev.h > > +++ b/lib/librte_ether/rte_ethdev.h > > @@ -857,6 +857,7 @@ struct rte_eth_conf { > > #define DEV_RX_OFFLOAD_TCP_LRO 0x00000010 > > #define DEV_RX_OFFLOAD_QINQ_STRIP 0x00000020 > > #define DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM 0x00000040 > > +#define DEV_RX_OFFLOAD_RESERVED_0 0x00000080 /**< Used for PMD-specific API. */ > > > > /** > > * TX offload capabilities of a device. > > @@ -874,6 +875,7 @@ struct rte_eth_conf { > > #define DEV_TX_OFFLOAD_GRE_TNL_TSO 0x00000400 /**< Used for tunneling packet. */ > > #define DEV_TX_OFFLOAD_IPIP_TNL_TSO 0x00000800 /**< Used for tunneling packet. */ > > #define DEV_TX_OFFLOAD_GENEVE_TNL_TSO 0x00001000 /**< Used for tunneling packet. */ > > +#define DEV_TX_OFFLOAD_RESERVED_0 0x00002000 /**< Used for PMD-specific API. */ > > > > /** > > * Ethernet device information > > -- > > 2.7.4 > > I am not sure how that supposed to work and how user should know that DEV_RX_OFFLOAD_RESERVED_0 > is actually a MACSEC for ixgbe? Users are not supposed to use DEV_RX_OFFLOAD_RESERVED_0, instead, they should use the capabilities and the likes defined in rte_pmd_ixgbe.h where the PMD-specifics APIs are declared: /** * If these flags are advertised by the PMD, the NIC supports the MACsec * offload. The incoming MACsec traffics can be offloaded transparently * after the MACsec offload is configured correctly by the application. * And the application can set the PKT_TX_IXGBE_MACSEC flag in mbufs to * enable the MACsec offload for the packets to be transmitted. */ #define DEV_RX_OFFLOAD_IXGBE_MACSEC_STRIP DEV_RX_OFFLOAD_RESERVED_0 #define DEV_TX_OFFLOAD_IXGBE_MACSEC_INSERT DEV_TX_OFFLOAD_RESERVED_0 /** * This event will occur when the PN counter in a MACsec connection * reach the exhaustion threshold. */ #define RTE_ETH_EVENT_IXGBE_MACSEC RTE_ETH_EVENT_RESERVED_0 /** * Offload the MACsec. This flag must be set by the application in mbuf * to enable this offload feature for a packet to be transmitted. */ #define PKT_TX_IXGBE_MACSEC PKT_TX_RESERVED_0 PMD-specific APIs can only be used on the corresponding driver/device, so different PMD can share the same reserved bit to represent different things when implementing their own PMD-specific APIs. > Another question what to do if you would like to create a bonded device over two devices with different NIC types? > As I understand you can end up in situation when DEV_RX_OFFLOAD_RESERVED_0 would mean different capabilities. > Why not to have this MACSEC capability and ol_flag value as generic ones, as you have them in previous versions of your patch? Those flags are only used in PMD-specific APIs. I don't think we could use the PMD-specific APIs provided by a certain PMD on a bonded device. Thanks & regards, Tiwei Bie