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 DB4EE1C7B2 for ; Wed, 4 Apr 2018 18:27:02 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 09:27:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,407,1517904000"; d="scan'208";a="217518400" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.42]) ([10.237.221.42]) by fmsmga006.fm.intel.com with ESMTP; 04 Apr 2018 09:27:00 -0700 To: "Ananyev, Konstantin" , "Dai, Wei" , "Zhang, Qi Z" , "Wang, Xiao W" Cc: "'dev@dpdk.org'" 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> <2601191342CEEE43887BDE71AB977258A0AB7CE6@irsmsx105.ger.corp.intel.com> From: Ferruh Yigit Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= xsFNBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABzSVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+wsF+BBMBAgAoAhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgAUCWZR1xgUJB33UawAKCRD5M+tD3xNhH3TID/wNjq1doFXg49WaM7ZXez/1 qwj7U6FQ2eUhlEPX8dXc52cu+iQk8/mssXQtANEx+jndxfvlkikBNgI+mr3m/ho54uQWFZd7 Bv0DVVkLHNkLWK6tT6iISdCgXrQuOv8y5rucEGkJ8dDPsp8Mqr4sBjavRBpczphoa3miKusA HzUEo0SYuHUPmBlbmvKv4PkA5quWtXpkgV2HZ1bW9X0dQkAqEVioAPm5Q6pXJODfV8kaZUtJ z4swEtBnK9XAWm2HccF7KmFh0vv+Zh9lEMnEFt7UPXngY6+xCTo6xV1IVc8EZfDjOip8I4h2 ALMaLgrZwA9VVmHCVOrnO3UZqfGehrwz4O3sUrcmIzxjk3gfBmVRCBfuWGchSpWtZ99U6V1a OEuG+ymyjBDtyymW+KSvmCBl2gIxZHvZFvSRRdDObkkUIskSJ95f/6HBOESRZBOiV9GEAhC5 gI9OAKKF8HQaN/r5KJrkzscjQcjIdV1jXhTkfQ4wH3GJiVM5JxsKsEjjRw7yfSJo2GBEGqMe KMwMLWg4f1DgVtjOuGf10isu+29MvapW2IxKYaHcVc2vHfWbDi2AvBj/VAzKILWbTEgI1VL5 zKpo5p6X2O55oEyeflDiAzrUfvLqB4vmTyqXtW6PdLyZC7kXIzmNu6EBVx9oSgy3CADw5saN 0La9OoCAc7Tn+s7BTQRX1ky+ARAApzQNvXvE2q1LAS+Z+ni2R13Bb1cDS1ZYq1jgpR13+OKN ipzd8MPngRJilXxBaPTErhgzR0vGcNTYhjGMSyFIHVOoBq1VbP1a0Fi/NqWzJOowo/fDfgVy K4vuitc/gCJs+2se4hdZA4EQJxVlNM51lgYDNpjPGIA43MX15OLAip73+ho6NPBMuc5qse3X pAClNhBKfENRCWN428pi3WVkT+ABRTE0taxjJNP7bb+9TQYNRqGwnGzX5/XISv44asWIQCaq vOkXSUJLd//cdVNTqtL1wreCVVR5pMXj7VIrlk07fmmJVALCmGbFr53BMb8O+8dgK2A5mitM n44d+8KdJWOwziRxcaMk/LclmZS3Iv1TERtiWt98Y9AjeAtcgYPkA3ld0BcUKONogP8pHVz1 Ed3s5rDQ91yr1S0wuAzW91fxGUO4wY+uPmxCtFVuBgd9VT9NAKTUL0qHM7CDgCnZPe0TW6Zj 8OqtdCCyAfvU9cW5xWM7Icxhde6AtPxhDSBwE8fL2ZmrDmaA4jmUKXp3i4JxRPSX84S08b+s DWXHPxy10UFU5A7EK/BEbZAKBwn9ROfm+WK+6X5xOGLoRE++OqNuUudxC1GDyLOPaqCbBCS9 +P6HsTHzxsjyJa27n4jcrcuY3P9TEcFJYSZSeSDh8mVGvugi0exnSJrrBZDyVCcAEQEAAcLB ZQQYAQIADwIbDAUCWZR1ZwUJA59cIQAKCRD5M+tD3xNhH5b+D/9XG44Ci6STdcA5RO/ur05J EE3Ux1DCHZ5V7vNAtX/8Wg4l4GZfweauXwuJ1w7Sp7fklwcNC6wsceI+EmNjGMqfIaukGetG +jBGqsQ7moOZodfXUoCK98gblKgt/BPYMVidzlGC8Q/+lZg1+o29sPnwImW+MXt/Z5az/Z17 Qc265g+p5cqJHzq6bpQdnF7Fu6btKU/kv6wJghENvgMXBuyThqsyFReJWFh2wfaKyuix3Zyj ccq7/blkhzIKmtFWgDcgaSc2UAuJU+x9nuYjihW6WobpKP/nlUDu3BIsbIq09UEke+uE/QK+ FJ8PTJkAsXOf1Bc2C0XbW4Y2hf103+YY6L8weUCBsWC5VH5VtVmeuh26ENURclwfeXhWQ9Og 77yzpTXWr5g1Z0oLpYpWPv745J4bE7pv+dzxOrFdM1xNkzY2pvXph/A8OjxZNQklDkHQ7PIB Lki5L2F4XkEOddUUQchJwzMqTPsggPDmGjgLZrqgO+s4ECZK5+nLD3HEpAbPa3JLDaScy+90 Nu1lAqPUHSnP3vYZVw85ZYm6UCxHE4VLMnnJsN09ZhsOSVR+GyP5Nyw9rT1V3lcsuH7M5Naa 2Xobn9m7l9bRCD/Ji8kG15eV1WTxx1HXVQGjdUYDI7UwegBNbwMLh17XDy+3sn/6SgcqtECA Q6pZKA2mTQxEKA== Message-ID: Date: Wed, 4 Apr 2018 17:26:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB977258A0AB7CE6@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Wed, 04 Apr 2018 16:27:03 -0000 On 4/3/2018 11:48 AM, Ananyev, Konstantin wrote: > > >> -----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 offloads API >> >> 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 size. >> For example, SCATTER is enabled on queue 0 with a small mem buffer size of mempool 0, >> And SCATTER is disabled on queue 1 with a large mem buffer size of mempool 1, >> Both queues can avoid packet dropping. >> Indeed, current fm10k PMD also automatically set FM10K_SRRCTL_BUFFER_CHAINING_EN >> If max_rx_pkt_len + 2 * VLAN_TAG_SIZE > mem_buf_size no matter whether SCATTER 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. I share the concern, having single Rx function for all queues but able to configure each queue separately for scattered rx seems confusing. Also it seems PMD is already giving this decision independent from scatter offload flag. I am ok to get patch as it is but I believe it worth thinking to change scatter offload to port level. > But again - up to you guys, both approaches are possible, I think. > Konstantin > >> >> >>> -----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 that >>>>>>>>> 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 = Any packet longer than the data buffer size is terminated with a >>>> TOO_BIG error status in Rx descriptor write-back. The remainder of the >>>> frame is not posted to host, it is silently dropped. >>>> 1b = A packet can be spread over more than one single receive data >>>> buffer >>>> >>> >>> Ok, that's a bit unusual approach but understandable. >>> Thanks >>> Konstantin