From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id AB604271 for ; Tue, 3 Apr 2018 12:48:08 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2018 03:48:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,400,1517904000"; d="scan'208";a="44496572" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by orsmga001.jf.intel.com with ESMTP; 03 Apr 2018 03:48:06 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.216]) by irsmsx110.ger.corp.intel.com ([169.254.15.211]) with mapi id 14.03.0319.002; Tue, 3 Apr 2018 11:48:05 +0100 From: "Ananyev, Konstantin" To: "Dai, Wei" , "Zhang, Qi Z" , "Wang, Xiao W" CC: "'dev@dpdk.org'" Thread-Topic: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API Thread-Index: AQHTxnytaXMQOEIDLkWau+9ilN6UWaPmqxIAgABHfuD///aVAIAAFTZA///1noCABOB/sIACw4+AgABM8jA= Date: Tue, 3 Apr 2018 10:48:05 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258A0AB7CE6@irsmsx105.ger.corp.intel.com> References: <20180302141105.4954-1-wei.dai@intel.com> <20180328080037.16207-1-wei.dai@intel.com> <20180328080037.16207-2-wei.dai@intel.com> <039ED4275CED7440929022BC67E706115317576C@SHSMSX103.ccr.corp.intel.com> <039ED4275CED7440929022BC67E7061153175E35@SHSMSX103.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258A0AB5BB9@irsmsx105.ger.corp.intel.com> <039ED4275CED7440929022BC67E7061153175FD0@SHSMSX103.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258A0AB5C19@irsmsx105.ger.corp.intel.com> <039ED4275CED7440929022BC67E706115317602B@SHSMSX103.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258A0AB71B4@irsmsx105.ger.corp.intel.com> <49759EB36A64CF4892C1AFEC9231E8D66CF66147@PGSMSX112.gar.corp.intel.com> In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D66CF66147@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjM1NjQ1NzYtMjFhNS00YTE4LWIxNmItZjUxOTkzNzcyYWM1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IllISmNZYzcrZWRHa29sM1FPK0tCa1NWeWFyMW9qZUZHUWNwZnp5azg4Ukk9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 1/2] net/fm10k: 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, 03 Apr 2018 10:48:09 -0000 > -----Original Message----- > From: Dai, Wei > Sent: Tuesday, April 3, 2018 8:11 AM > To: Ananyev, Konstantin ; Zhang, Qi Z ; Wang, Xiao W > Cc: 'dev@dpdk.org' > Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offlo= ads API >=20 > Thanks, Konstantin and Zhang Qi for your feedback and support. > I have talked with Qi and know following: > To avoid packet dropping when FM10K_SRRCTL_BUFFER_CHAINING_EN is not set, > the queue can work with a different mempool which has larger mem buffer s= ize. > For example, SCATTER is enabled on queue 0 with a small mem buffer size o= f mempool 0, > And SCATTER is disabled on queue 1 with a large mem buffer size of mempoo= l 1, > Both queues can avoid packet dropping. > Indeed, current fm10k PMD also automatically set FM10K_SRRCTL_BUFFER_CHAI= NING_EN > If max_rx_pkt_len + 2 * VLAN_TAG_SIZE > mem_buf_size no matter whether SC= ATTER is enabled > on queue configuration or not. You can make it just MULTISEG a port offload (not queue) and in that case none of the queues will drop the packets. But again - up to you guys, both approaches are possible, I think. Konstantin >=20 >=20 > > -----Original Message----- > > From: Ananyev, Konstantin > > Sent: Sunday, April 1, 2018 8:09 PM > > To: Zhang, Qi Z ; Dai, Wei ; > > Wang, Xiao W > > Cc: 'dev@dpdk.org' > > Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx > > offloads API > > > > Hi Qi, > > > > > > > > > > > > > > > > > > Hi Daiwei: > > > > > > > > > > > > > > > > > +static uint64_t fm10k_get_rx_queue_offloads_capa(struct > > > > > > > > > +rte_eth_dev > > > > > > > > > +*dev) { > > > > > > > > > + RTE_SET_USED(dev); > > > > > > > > > + > > > > > > > > > + return (uint64_t)(DEV_RX_OFFLOAD_SCATTER); > > > > > > > > > +} > > > > > > > > > > > > > > > > why per queue rx scattered feature here? > > > > > > > > My understanding is either we use scattered rx function tha= t > > > > > > > > enable this feature for all queues or we use non-scattered > > > > > > > > rx function that disable this feature for all queues, right= ? > > > > > > > > > > > > > > Checked with Dai Wei offline, fm10k have per queue register > > > > > > > that can be configured to support rx scattered, So it is per = queue > > offload. > > > > > > > > > > > > Ok, but these days we have one RX function per device. > > > > > > Looking at fm10k - it clearly has different RX function for > > > > > > scattered and non-scattered case. > > > > > > Yes, HW does support scatter/non-scatter selection per queue, > > > > > > but our SW - doesn't (same for ixgbe and i40e) So how it could > > > > > > be per queue > > > > offload? > > > > > > > > > > We saw the implementation of fm10k is a little bit different with= i40e. > > > > > It set per queue register "FM10K_SRRCTL_BUFFER_CHAINING_EN" to > > > > > turn > > > > on multi-seg feature when offload is required. > > > > > > > > > > That means two queues can have different behavior when process a > > > > > packet that exceed the buffer size base on the register setting, > > > > > though we > > > > use the same rx scattered function, so we think this is per queue > > > > feature, is that make sense? > > > > > > > > Ok, suppose we have 2 functions configured. > > > > One with DEV_RX_OFFLOAD_SCATTER is on, second with > > > > DEV_RX_OFFLOAD_SCATTER is off. > > > > So scatter RX function will be selected, but for second queue HW > > > > support will not be enabled, so packets bigger then RX buffer will > > > > be silently dropped by HW, right? > > > > > > Yes according to datasheet > > > > > > Bit FM10K_SRRCTL_BUFFER_CHAINING_EN: > > > > > > 0b =3D Any packet longer than the data buffer size is terminated with= a > > > TOO_BIG error status in Rx descriptor write-back. The remainder of th= e > > > frame is not posted to host, it is silently dropped. > > > 1b =3D A packet can be spread over more than one single receive data > > > buffer > > > > > > > Ok, that's a bit unusual approach but understandable. > > Thanks > > Konstantin