From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9ECF4A04B7; Wed, 14 Oct 2020 14:31:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 089B31DCCB; Wed, 14 Oct 2020 14:31:49 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 1BC991DC7A for ; Wed, 14 Oct 2020 14:31:47 +0200 (CEST) IronPort-SDR: Vvu5/sBvwORO4Bi3n8ydG/f+T5stb8bFpo7LQ6hOT0pxim7FxdghUhPweCrW7Ov3LjBF7yirkG n6Ojsx8GpAfA== X-IronPort-AV: E=McAfee;i="6000,8403,9773"; a="162624570" X-IronPort-AV: E=Sophos;i="5.77,374,1596524400"; d="scan'208";a="162624570" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2020 05:31:45 -0700 IronPort-SDR: 0k9eipcSK8KiNY47Fvc6bFhrClFTUaEnNs7vhZ64D25IdqGrBnQP6iSOfKMp+xcWIH9PhSaGEA boVIM81P2ajA== X-IronPort-AV: E=Sophos;i="5.77,374,1596524400"; d="scan'208";a="345642016" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.2.249]) ([10.252.2.249]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2020 05:31:43 -0700 To: Jeff Guo , jingjing.wu@intel.com, qi.z.zhang@intel.com, beilei.xing@intel.com Cc: dev@dpdk.org, haiyue.wang@intel.com, Bruce Richardson , Olivier Matz References: <20200909025415.6185-1-jia.guo@intel.com> <20201013081734.47507-1-jia.guo@intel.com> From: Ferruh Yigit Message-ID: <0257ccb2-88eb-a49a-77f9-9e611f3c266a@intel.com> Date: Wed, 14 Oct 2020 13:31:39 +0100 MIME-Version: 1.0 In-Reply-To: <20201013081734.47507-1-jia.guo@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v8] net/iavf: support flex desc metadata extraction 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/13/2020 9:17 AM, Jeff Guo wrote: > Enable metadata extraction for flexible descriptors in AVF, that would > allow network function directly get metadata without additional parsing > which would reduce the CPU cost for VFs. The enabling metadata > extractions involve the metadata of VLAN/IPv4/IPv6/IPv6-FLOW/TCP/MPLS > flexible descriptors, and the VF could negotiate the capability of > the flexible descriptor with PF and correspondingly configure the > specific offload at receiving queues. > > Signed-off-by: Jeff Guo > Acked-by: Haiyue Wang > --- > v8: > rebase patch for apply issue > > v7: > clean some useless and add doc > > v6: > rebase patch > > v5: > remove ovs configure since ovs is not protocol extraction > > v4: > add flex desc type in rx queue for handling vector path > handle ovs flex type > > v3: > export these global symbols into .map > > v2: > remove makefile change and modify the rxdid handling > --- > config/rte_config.h | 3 + > doc/guides/nics/intel_vf.rst | 16 + > doc/guides/rel_notes/release_20_11.rst | 6 + > drivers/net/iavf/iavf.h | 24 +- > drivers/net/iavf/iavf_ethdev.c | 394 ++++++++++++++++++++++ > drivers/net/iavf/iavf_rxtx.c | 252 ++++++++++++-- > drivers/net/iavf/iavf_rxtx.h | 168 +++++---- > drivers/net/iavf/iavf_rxtx_vec_common.h | 3 + > drivers/net/iavf/iavf_vchnl.c | 22 +- > drivers/net/iavf/meson.build | 2 + > drivers/net/iavf/rte_pmd_iavf.h | 250 ++++++++++++++ > drivers/net/iavf/rte_pmd_iavf_version.map | 13 + > 12 files changed, 1039 insertions(+), 114 deletions(-) > create mode 100644 drivers/net/iavf/rte_pmd_iavf.h > > diff --git a/config/rte_config.h b/config/rte_config.h > index 03d90d78bc..2c53072c3d 100644 > --- a/config/rte_config.h > +++ b/config/rte_config.h > @@ -127,6 +127,9 @@ > #define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF 4 > #define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM 4 > > +/* iavf defines */ > +#undef RTE_LIBRTE_IAVF_16BYTE_RX_DESC > + Hi Jeff, The 'RTE_LIBRTE_IAVF_16BYTE_RX_DESC' was already there, not introduced with this patch, so I think better to add this change as different patch. Also not sure if we want to add more config options to the 'rte_config.h', indeed otherway around and we are trying to get rid of as much as compile time optios. cc'ed Bruce too. > /* Ring net PMD settings */ > #define RTE_PMD_RING_MAX_RX_RINGS 16 > #define RTE_PMD_RING_MAX_TX_RINGS 16 > diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst > index ade5152595..207f456143 100644 > --- a/doc/guides/nics/intel_vf.rst > +++ b/doc/guides/nics/intel_vf.rst > @@ -615,3 +615,19 @@ which belongs to the destination VF on the VM. > .. figure:: img/inter_vm_comms.* > > Inter-VM Communication > + > + > +Pre-Installation Configuration > +------------------------------ > + > +Config File Options > +~~~~~~~~~~~~~~~~~~~ > + > +The following options can be modified in the ``config`` file. > +Please note that enabling debugging options may affect system performance. > + > +- ``CONFIG_RTE_LIBRTE_IAVF_16BYTE_RX_DESC`` (default ``n``) There is no 'CONFIG_RTE_LIBRTE_IAVF_16BYTE_RX_DESC' anymore, this is from make days naming. Instead, what do you think not adding the 'RTE_LIBRTE_IAVF_16BYTE_RX_DESC' to the 'rte_config.h', but document how this flag can be provided by meson during build: meson -Dc_args="-DRTE_LIBRTE_IAVF_16BYTE_RX_DESC" And we should plan for long term to convert this compile time flag to runtime devargs. What do you think? > + > + Toggle to use a 16-byte RX descriptor, by default the RX descriptor is 32 byte. > + Configure to 16-byte Rx descriptor may cause a negotiation failure during VF driver initialization > + if the PF driver doesn't support. > diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst > index e7691ee732..93d3ccc60a 100644 > --- a/doc/guides/rel_notes/release_20_11.rst > +++ b/doc/guides/rel_notes/release_20_11.rst > @@ -160,6 +160,12 @@ New Features > packets with specified ratio, and apply with own set of actions with a fate > action. When the ratio is set to 1 then the packets will be 100% mirrored. > > +* **Updated Intel iavf driver.** > + > + Updated iavf PMD with new features and improvements, including: > + > + * Added support for flexible descriptor metadata extraction. > + Can you please move the update to the net drivers block, instead of very bottom. There is an order in the release notes (as commented in section header) like: - core libs - ethdev lib related changes - ethdev PMDS change - ... <...> > + > +EXPERIMENTAL { > + global: > + > + # added in 20.11 > + rte_net_iavf_dynfield_proto_xtr_metadata_offs; > + rte_net_iavf_dynflag_proto_xtr_vlan_mask; > + rte_net_iavf_dynflag_proto_xtr_ipv4_mask; > + rte_net_iavf_dynflag_proto_xtr_ipv6_mask; > + rte_net_iavf_dynflag_proto_xtr_ipv6_flow_mask; > + rte_net_iavf_dynflag_proto_xtr_tcp_mask; > + rte_net_iavf_dynflag_proto_xtr_ip_offset_mask; As a namespace previously "rte_pmd_xxx" was used for PMD specific APIs, can you please switch to that? 'rte_net_' is used by the 'librte_net' library. Above list is the dynfield values, what is the correct usage for dynfields, 1- Put dynfileds names in to the header, and application does a lookup ('rte_mbuf_dynfield_lookup()') to get the dynfield values. or 2- Expose dynfield values to be accessed directly from application, as done above. @Oliver, can you please support. I can see (1) has advantage of portability if more than one PMD supports same dynfield names, but that sees not a case for above ones.