From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 3647216E for ; Tue, 20 Mar 2018 12:53:17 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2018 04:53:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,335,1517904000"; d="scan'208";a="26845885" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga008.jf.intel.com with ESMTP; 20 Mar 2018 04:53:15 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.216]) by IRSMSX104.ger.corp.intel.com ([169.254.5.171]) with mapi id 14.03.0319.002; Tue, 20 Mar 2018 11:53:15 +0000 From: "Ananyev, Konstantin" To: "Dai, Wei" , "Lu, Wenzhuo" CC: "dev@dpdk.org" Thread-Topic: [PATCH v2 3/4] net/ixgbe: convert to new Rx offloads API Thread-Index: AQHTthefIevzRcekXUubE36V2QkKx6PQSZLAgAarMICAAXqeoA== Date: Tue, 20 Mar 2018 11:53:15 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258A0AB20F4@irsmsx105.ger.corp.intel.com> References: <1519747291-6969-1-git-send-email-wei.dai@intel.com> <1520427990-73471-1-git-send-email-wei.dai@intel.com> <1520427990-73471-4-git-send-email-wei.dai@intel.com> <2601191342CEEE43887BDE71AB9772589E28FDBA@irsmsx105.ger.corp.intel.com> <49759EB36A64CF4892C1AFEC9231E8D66CF60396@PGSMSX112.gar.corp.intel.com> In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D66CF60396@PGSMSX112.gar.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTcyNTk4NGItODhhZi00MTA1LTkzYTAtNzdjYTdiMTJiNzkwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImkxbE9wVXR3V1NXazVsamNUZWtuQ3VNV0taQkU2aVNCUTV4aG1hcDh4Ymc9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 3/4] net/ixgbe: convert to new Rx offloads 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: Tue, 20 Mar 2018 11:53:18 -0000 Hi Wei, >=20 > Hi, Konstantin > Thanks for your feedback. >=20 > > -----Original Message----- > > From: Ananyev, Konstantin > > Sent: Thursday, March 15, 2018 5:48 AM > > To: Dai, Wei ; Lu, Wenzhuo > > Cc: dev@dpdk.org > > Subject: RE: [PATCH v2 3/4] net/ixgbe: convert to new Rx offloads API > > > > Hi Wei, > > > > > -----Original Message----- > > > From: Dai, Wei > > > Sent: Wednesday, March 7, 2018 1:06 PM > > > To: Lu, Wenzhuo ; Ananyev, Konstantin > > > > > > Cc: dev@dpdk.org; Dai, Wei > > > Subject: [PATCH v2 3/4] net/ixgbe: convert to new Rx offloads API > > > > > > Ethdev Rx offloads API has changed since: > > > commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API") This > > > commit support the new Rx offloads API. > > > > > > Signed-off-by: Wei Dai > > > --- > > > drivers/net/ixgbe/ixgbe_ethdev.c | 93 +++++++++-------- > > > drivers/net/ixgbe/ixgbe_ipsec.c | 8 +- > > > drivers/net/ixgbe/ixgbe_rxtx.c | 163 > > ++++++++++++++++++++++++++---- > > > drivers/net/ixgbe/ixgbe_rxtx.h | 3 + > > > drivers/net/ixgbe/ixgbe_rxtx_vec_common.h | 2 +- > > > drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 2 +- > > > 6 files changed, 205 insertions(+), 66 deletions(-) > > > > > > +uint64_t > > > +ixgbe_get_rx_queue_offloads(struct rte_eth_dev *dev) { > > > + uint64_t offloads; > > > + struct ixgbe_hw *hw =3D > > > +IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private); > > > + > > > + offloads =3D DEV_RX_OFFLOAD_HEADER_SPLIT; > > > > As I can see I ixgbe all header_split code is enabled only if > > RTE_HEADER_SPLIT_ENABLE is on. > > It is off by default and I doubt anyone really using it these days. > > So I think the best thing would be not to advertise > > DEV_RX_OFFLOAD_HEADER_SPLIT for ixgbe at all, and probably remove > > related code. > > If you'd prefer to keep it, then at least we should set that capability= only at > > #ifdef RTE_HEADER_SPLIT_ENABLE. > > Another thing - it should be per port, not per queue. > > Thought I think better is just to remove it completely. > I will set this header splitting capability in #ifdef RTE_HEADER_SPLIT_EN= ABLE in my next patch set. > I think it is a per queue capability as it can be configured on the regis= ter IXGBE_SRRCTL of every Rx queue > In this code line: IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(rxq->reg_idx), srrctl= ); in ixgbe_dev_rx_init( ). > Same case is also in the code line: IXGBE_WRITE_REG(hw, IXGBE_VFSRRCTL(i)= , srrctl); in ixgbevf_dev_rx_init( ). Yes, HW can enable/disable it on a per queue basis. Though it affects rx function selection, and as right now we have one rx fu= nction per device - That's why it looks to me more like a per port offload. Though I believe these days ixgbe PMD doesn't support it properly anyway=20 (we always set rxd.hdr_addr to zero) - so probably better to remove it at a= ll. >=20 > > > +static int > > > +ixgbe_check_rx_queue_offloads(struct rte_eth_dev *dev, uint64_t > > > +requested) { > > > + uint64_t port_offloads =3D dev->data->dev_conf.rxmode.offloads; > > > + uint64_t queue_supported =3D ixgbe_get_rx_queue_offloads(dev); > > > + uint64_t port_supported =3D ixgbe_get_rx_port_offloads(dev); > > > + > > > + if ((requested & (queue_supported | port_supported)) !=3D requested= ) > > > + return 0; > > > + > > > + if ((port_offloads ^ requested) & port_supported) > > > > Could you explain a bit more what are you cheking here? > > As I can see: > > (port_offloads ^ requested) - that's a diff between already set and ne= wly > > requested offloads. > > Then you check if that diff consists of supported by port offloads, and= if yes > > you return an error? > > Konstantin > > > This function is similar to mlx4_check_rx_queue_offloads() in mlx4 driver= . > As the git log message in the commit ce17eddefc20285bbfe575bdc07f42f0b20f= 34cb say > that a per port capability should has same setting (enabling or disabling= ) on both port > configuration via rte_eth_dev_configure( ) and queue configuration via rt= e_eth_rx_queue_setup( ). > This function check if this requirement is matched or not. > It also check offloading request is supported as a per port or a per queu= e capability or not. > If above checking is pass, it return 1 else return 0. Ok, let be more specific here. Let say: requested =3D=3D DEV_RX_OFFLOAD_VLAN_STRIP; port_offloads =3D=3D DEV_RX_OFFLOAD_IPV4_CKSUM; port_supported =3D (DEV_RX_OFFLOAD_IPV4_CKSUM | DEV_RX_OFFLOAD_UDP_CKSUM | DEV_RX_OFFLOAD_TCP_CKSUM | DEV_RX_OFFLOAD_CRC_STRIP | DEV_RX_OFFLOAD_JUMBO_FRAME | DEV_RX_OFFLOAD_SCATTER); (port_offloads ^ requested) =3D=3D DEV_RX_OFFLOAD_VLAN_STRIP | DEV_RX_OFFLO= AD_IPV4_CKSUM; (port_offloads ^ requested) & port_supported =3D=3D DEV_RX_OFFLOAD_IPV4_CKS= UM; And that function will return failure, while as I understand it shouldn't -= requested queue offload is valid. Konstantin