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 8E611A04DB; Thu, 15 Oct 2020 10:33:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E269E1DD07; Thu, 15 Oct 2020 10:33:46 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id F022A1DCF6 for ; Thu, 15 Oct 2020 10:33:44 +0200 (CEST) IronPort-SDR: Mnr48AuN09K5kj8wPxr6INguzttuihqOUHPZn0tV55yifHNKfBQ77NY0ON8eNPQq/NvxGsV2jt DqV0/AfvbwVQ== X-IronPort-AV: E=McAfee;i="6000,8403,9774"; a="183832632" X-IronPort-AV: E=Sophos;i="5.77,378,1596524400"; d="scan'208";a="183832632" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2020 01:33:43 -0700 IronPort-SDR: bfheWixxgWknOIysaUIsacPcCq6jBpMnOZAit8+fOf9pGp1jd01tOTOo/k5QeRgsK32+2NzSi8 /aIs6FF3CuDA== X-IronPort-AV: E=Sophos;i="5.77,378,1596524400"; d="scan'208";a="464207726" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.251.84.112]) ([10.251.84.112]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2020 01:33:40 -0700 To: "Guo, Jia" , "Wu, Jingjing" , "Zhang, Qi Z" , "Xing, Beilei" Cc: "dev@dpdk.org" , "Wang, Haiyue" , "Richardson, Bruce" , Olivier Matz References: <20200909025415.6185-1-jia.guo@intel.com> <20201013081734.47507-1-jia.guo@intel.com> <0257ccb2-88eb-a49a-77f9-9e611f3c266a@intel.com> <82ad9cd928c24e798de6dd6fe2001099@intel.com> From: Ferruh Yigit Message-ID: <98923032-4ef6-a1cd-e067-2b2ef6f6a90e@intel.com> Date: Thu, 15 Oct 2020 09:33:36 +0100 MIME-Version: 1.0 In-Reply-To: <82ad9cd928c24e798de6dd6fe2001099@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/15/2020 6:26 AM, Guo, Jia wrote: > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Wednesday, October 14, 2020 8:32 PM >> To: Guo, Jia ; Wu, Jingjing ; >> Zhang, Qi Z ; Xing, Beilei >> Cc: dev@dpdk.org; Wang, Haiyue ; Richardson, >> Bruce ; Olivier Matz >> Subject: Re: [PATCH v8] net/iavf: support flex desc metadata extraction >> >> 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? >> > > Sorry, I miss this comment. And, I agree on. Too more compile time flag is not friendly to use. Do you agree to do the runtime devargs on next separate patch set? > Sure, OK to have it as separate patchset. >>> + >>> + 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 >> - ... >> > > Sure, will update it in v10. > >> <...> >> >>> + >>> +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. >> > > Make sense. > >> 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.