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 1D873A04B1; Wed, 23 Sep 2020 10:22:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7C3F01DB99; Wed, 23 Sep 2020 10:22:46 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 3F1DE1DB98 for ; Wed, 23 Sep 2020 10:22:45 +0200 (CEST) IronPort-SDR: fIIHPGPrQ0HYt7+r7cdJzzSzd2yJrCjv2XOLhk76HvFrd39qbqWo7FBgzQJWNC3YgXjDm0qWFh VT5Is5UJ2F2Q== X-IronPort-AV: E=McAfee;i="6000,8403,9752"; a="224964084" X-IronPort-AV: E=Sophos;i="5.77,293,1596524400"; d="scan'208";a="224964084" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2020 01:22:43 -0700 IronPort-SDR: k0bmHZPage75pr7Pr6KepNjEa+GEaP5ZjQnU4w9F/y5z0RaFe4gGCBK6PvTxtZ3w1uxxJpNLmU Qz3UUrK07A0Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,293,1596524400"; d="scan'208";a="290716974" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga007.fm.intel.com with ESMTP; 23 Sep 2020 01:22:43 -0700 Received: from shsmsx605.ccr.corp.intel.com (10.109.6.215) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 23 Sep 2020 01:22:43 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX605.ccr.corp.intel.com (10.109.6.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 23 Sep 2020 16:22:41 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.1713.004; Wed, 23 Sep 2020 16:22:41 +0800 From: "Guo, Jia" To: "Wang, Haiyue" , "Wu, Jingjing" , "Zhang, Qi Z" , "Xing, Beilei" CC: "dev@dpdk.org" Thread-Topic: [PATCH v3] net/iavf: support flex desc metadata extraction Thread-Index: AQHWkX8EDMeuomgyxEGTNPw88ocsw6l1WPAAgACIhtA= Date: Wed, 23 Sep 2020 08:22:41 +0000 Message-ID: <1be1daed074645b9bdcd5c3d828a8be9@intel.com> References: <20200909025415.6185-1-jia.guo@intel.com> <20200923075240.106481-1-jia.guo@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3] 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" > -----Original Message----- > From: Wang, Haiyue > Sent: Wednesday, September 23, 2020 4:11 PM > To: Guo, Jia ; Wu, Jingjing ; > Zhang, Qi Z ; Xing, Beilei > Cc: dev@dpdk.org > Subject: RE: [PATCH v3] net/iavf: support flex desc metadata extraction >=20 > > -----Original Message----- > > From: Guo, Jia > > Sent: Wednesday, September 23, 2020 15:53 > > To: Wu, Jingjing ; Zhang, Qi Z > > ; Xing, Beilei > > Cc: dev@dpdk.org; Wang, Haiyue ; Guo, Jia > > > > Subject: [PATCH v3] net/iavf: support flex desc metadata extraction > > > > 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 > > --- > > v3: > > export these global symbols into .map > > > > v2: > > remove makefile change and modify the rxdid handling > > --- > > doc/guides/rel_notes/release_20_11.rst | 6 + > > drivers/net/iavf/iavf.h | 25 +- > > drivers/net/iavf/iavf_ethdev.c | 395 ++++++++++++++++++++++ > > drivers/net/iavf/iavf_rxtx.c | 282 +++++++++++++-- > > drivers/net/iavf/iavf_rxtx.h | 233 +++++++------ > > 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 + > > 9 files changed, 1081 insertions(+), 147 deletions(-) create mode > > 100644 drivers/net/iavf/rte_pmd_iavf.h > > >=20 >=20 > > +enum iavf_flex_desc_type { > > +IAVF_FLEX_DESC_NONE, > > +IAVF_FLEX_DESC_VLAN, > > +IAVF_FLEX_DESC_IPV4, > > +IAVF_FLEX_DESC_IPV6, > > +IAVF_FLEX_DESC_IPV6_FLOW, > > +IAVF_FLEX_DESC_TCP, > > +IAVF_FLEX_DESC_OVS, > > +IAVF_FLEX_DESC_IP_OFFSET, > > +IAVF_FLEX_DESC_MAX, > > +}; >=20 > The vector PMD will also support extract the above data type ? Take ice a= s an > example, if user specifies the 'proto_xtr', the vector Rx path will be di= sabled, > it will be handled in C function. >=20 > enum proto_xtr_type { > PROTO_XTR_NONE, > PROTO_XTR_VLAN, > PROTO_XTR_IPV4, > PROTO_XTR_IPV6, > PROTO_XTR_IPV6_FLOW, > PROTO_XTR_TCP, > PROTO_XTR_IP_OFFSET, > PROTO_XTR_MAX /* The last one */ > }; >=20 > static inline int > ice_rx_vec_queue_default(struct ice_rx_queue *rxq) { ... >=20 > if (rxq->proto_xtr !=3D PROTO_XTR_NONE) > return -1; >=20 > return 0; > } >=20 You are right, vector will not support extraction, the version lack of hand= ling for that. >=20 > > -- > > 2.20.1 >=20