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 5AC00A04E1; Tue, 22 Sep 2020 08:33:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B19B31D5BE; Tue, 22 Sep 2020 08:33:40 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 5D1AF1D5B1 for ; Tue, 22 Sep 2020 08:33:39 +0200 (CEST) IronPort-SDR: tn4hZbhk6p4ooKX4luUw2p+Mop/18MvzF84l7yVF7aLy2rwuLCuBf1kq8zGY4QSiY4Tyo3EdSZ WTQZOTdc73ZA== X-IronPort-AV: E=McAfee;i="6000,8403,9751"; a="157924351" X-IronPort-AV: E=Sophos;i="5.77,289,1596524400"; d="scan'208";a="157924351" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 23:33:38 -0700 IronPort-SDR: GiEjDiBghlJtSn6qj6ZAmTSzBC2Pvm49UNBC9NOqV9SDlXK2YCiL/7AKCFDUwSyg6dGR83hJsc 4XrTE6JcOWTA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,289,1596524400"; d="scan'208";a="322113921" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga002.jf.intel.com with ESMTP; 21 Sep 2020 23:33:37 -0700 Received: from shsmsx604.ccr.corp.intel.com (10.109.6.214) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 21 Sep 2020 23:33:36 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX604.ccr.corp.intel.com (10.109.6.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 22 Sep 2020 14:33:34 +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; Tue, 22 Sep 2020 14:33:34 +0800 From: "Guo, Jia" To: "Wang, Haiyue" , "dev@dpdk.org" CC: "Zhang, Qi Z" , "Jiang, JunyuX" , "Rong, Leyi" , "Yang, Qiming" , "Sun, GuinanX" , "Guo, Junfeng" Thread-Topic: [PATCH v3] net/ice: refactor the Rx FlexiMD handling Thread-Index: AQHWjVqGsoqCf+Q0+0qVVpR7y2Zz86l0IpMg//+C3QCAAIcrkP//gGGAgACGfSD//32cgAARBKnA Date: Tue, 22 Sep 2020 06:33:34 +0000 Message-ID: <32ad1a4abebb495495a1f94ffd071219@intel.com> References: <20200917115332.45663-1-haiyue.wang@intel.com> <20200918010535.27089-1-haiyue.wang@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/ice: refactor the Rx FlexiMD handling 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: Tuesday, September 22, 2020 2:24 PM > To: Guo, Jia ; dev@dpdk.org > Cc: Zhang, Qi Z ; Jiang, JunyuX > ; Rong, Leyi ; Yang, Qiming > ; Sun, GuinanX ; Guo, > Junfeng > Subject: RE: [PATCH v3] net/ice: refactor the Rx FlexiMD handling >=20 > > -----Original Message----- > > From: Guo, Jia > > Sent: Tuesday, September 22, 2020 14:15 > > To: Wang, Haiyue ; dev@dpdk.org > > Cc: Zhang, Qi Z ; Jiang, JunyuX > > ; Rong, Leyi ; Yang, > > Qiming ; Sun, GuinanX ; > > Guo, Junfeng > > Subject: RE: [PATCH v3] net/ice: refactor the Rx FlexiMD handling > > > > > > > -----Original Message----- > > > From: Wang, Haiyue > > > Sent: Tuesday, September 22, 2020 2:09 PM > > > To: Guo, Jia ; dev@dpdk.org > > > Cc: Zhang, Qi Z ; Jiang, JunyuX > > > ; Rong, Leyi ; Yang, > > > Qiming ; Sun, GuinanX > > > ; Guo, Junfeng > > > Subject: RE: [PATCH v3] net/ice: refactor the Rx FlexiMD handling > > > > > > > -----Original Message----- > > > > From: Guo, Jia > > > > Sent: Tuesday, September 22, 2020 13:51 > > > > To: Wang, Haiyue ; dev@dpdk.org > > > > Cc: Zhang, Qi Z ; Jiang, JunyuX > > > > ; Rong, Leyi ; Yang, > > > > Qiming ; Sun, GuinanX > > > > ; Guo, Junfeng > > > > Subject: RE: [PATCH v3] net/ice: refactor the Rx FlexiMD handling > > > > > > > > > > > > > -----Original Message----- > > > > > From: Wang, Haiyue > > > > > Sent: Tuesday, September 22, 2020 1:42 PM > > > > > To: Guo, Jia ; dev@dpdk.org > > > > > Cc: Zhang, Qi Z ; Jiang, JunyuX > > > > > ; Rong, Leyi ; > > > > > Yang, Qiming ; Sun, GuinanX > > > > > ; Guo, Junfeng > > > > > Subject: RE: [PATCH v3] net/ice: refactor the Rx FlexiMD > > > > > handling > > > > > > > > > > Hi Jeff, > > > > > > > > > > > -----Original Message----- > > > > > > From: Guo, Jia > > > > > > Sent: Tuesday, September 22, 2020 13:35 > > > > > > To: Wang, Haiyue ; dev@dpdk.org > > > > > > Cc: Zhang, Qi Z ; Jiang, JunyuX > > > > > > ; Rong, Leyi ; > > > > > > Yang, Qiming ; Sun, GuinanX > > > > > > ; Guo, Junfeng > > > > > > Subject: RE: [PATCH v3] net/ice: refactor the Rx FlexiMD > > > > > > handling > > > > > > > > > > > > Hi, haiyue > > > > > > > > > > > > > > > > + struct rte_mbuf *mb, > > > > > > > + volatile union ice_rx_flex_desc *rxdp) { volatile struct > > > > > > > +ice_32b_rx_flex_desc_comms_ovs *desc =3D (volatile struct > > > > > > > +ice_32b_rx_flex_desc_comms_ovs > > > > > > > *)rxdp; #ifndef > > > > > > > +RTE_LIBRTE_ICE_16BYTE_RX_DESC uint16_t stat_err; #endif > > > > > > > > > > > > This #ifndef could be better combine with below #ifndef. > > > > > > > > > > > > > > > > I changed it to according to the different offsets, like ovs has > > > > > rss hash in Qword 3, which is after flow Id Qword 1, others are > > > > > opposite. So that this handling order can reflect the offset > > > > > difference, although, it MAY looks not so beautiful. What do you > > > > > think ? :) > > > > > > > > > > > > > I am not sure I got you point about the order reason, but I think > > > > in or out #ifndef should be clear show the offset difference, > > > > > > You mean below ? If so, 'uint16_t stat_err;' is not so good in the > > > middle of two code blocks. > > > > > > #ifndef RTE_LIBRTE_ICE_16BYTE_RX_DESC uint16_t stat_err; > > > > > > stat_err =3D rte_le_to_cpu_16(desc->status_error0); > > > if (likely(stat_err & (1 << ICE_RX_FLEX_DESC_STATUS0_RSS_VALID_S))) > > > { > > > mb->ol_flags |=3D PKT_RX_RSS_HASH; > > > mb->hash.rss =3D rte_le_to_cpu_32(desc->rss_hash); > > > } > > > #endif > > > > > > > Sorry, let me show clear as below > > > > #ifndef RTE_LIBRTE_ICE_16BYTE_RX_DESC > > uint16_t stat_err; > > > > stat_err =3D rte_le_to_cpu_16(desc->status_error0); > > if (likely(stat_err & (1 << ICE_RX_FLEX_DESC_STATUS0_RSS_VALID_S))) { > > mb->ol_flags |=3D PKT_RX_RSS_HASH; > > mb->hash.rss =3D rte_le_to_cpu_32(desc->rss_hash); > > } > > #endif > > > > if (desc->flow_id !=3D 0xFFFFFFFF) { > > mb->ol_flags |=3D PKT_RX_FDIR | PKT_RX_FDIR_ID; hash.fdir.hi =3D > > mb->rte_le_to_cpu_32(desc->flow_id); > > } > > >=20 > That's what I said about the order, you can check > "ice_rxd_to_pkt_fields_by_comms_ovs" > vs "ice_rxd_to_pkt_fields_by_comms_aux_v1" about "desc->flow_id" and > "desc->rss_hash" > handling order: offset first, handle it firstly. >=20 I know your point and you could choose if need more doc to highlight this o= ffset change or not. Anyway, I am not insist object for this order. > > > > > > > +uint64_t xtr_ol_flag; /* Protocol extraction offload flag > > > > > > > +*/ ice_rxd_to_pkt_fields_t rxd_to_pkt_fields; > > > > > > > > > > > > If create a function pointer here in .h, it is better add some = doc. > > > > > > C comments: /* .... */ ? > > > > > > > Yes. >=20 > OK. >=20 > > > > > > > > > > > > > > > ice_rx_release_mbufs_t rx_rel_mbufs; }; > > > > > > > > > > > > > > -- > > > > > > > 2.28.0 > > > > > > > > > > > > > > > > > > > > >=20