> -----Original Message----- > From: Ananyev, Konstantin > Sent: Thursday, March 29, 2018 6:21 PM > To: Zhang, Qi Z <qi.z.zh...@intel.com>; Dai, Wei <wei....@intel.com>; Wang, > Xiao W <xiao.w.w...@intel.com> > Cc: 'dev@dpdk.org' <dev@dpdk.org> > Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx > offloads API > > Hi Qi, > > > -----Original Message----- > > From: Zhang, Qi Z > > Sent: Thursday, March 29, 2018 10:51 AM > > To: Ananyev, Konstantin <konstantin.anan...@intel.com>; Dai, Wei > > <wei....@intel.com>; Wang, Xiao W <xiao.w.w...@intel.com> > > Cc: 'dev@dpdk.org' <dev@dpdk.org> > > Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx > > offloads API > > > > Hi Konstantin: > > > > > -----Original Message----- > > > From: Ananyev, Konstantin > > > Sent: Thursday, March 29, 2018 5:29 PM > > > To: Zhang, Qi Z <qi.z.zh...@intel.com>; Dai, Wei > > > <wei....@intel.com>; Wang, Xiao W <xiao.w.w...@intel.com> > > > Cc: 'dev@dpdk.org' <dev@dpdk.org> > > > Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx > > > offloads API > > > > > > > > > > > > > -----Original Message----- > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhang, Qi Z > > > > Sent: Thursday, March 29, 2018 7:09 AM > > > > To: Dai, Wei <wei....@intel.com>; Wang, Xiao W > > > > <xiao.w.w...@intel.com> > > > > Cc: 'dev@dpdk.org' <dev@dpdk.org> > > > > Subject: Re: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new > > > > Rx offloads API > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Zhang, Qi Z > > > > > Sent: Wednesday, March 28, 2018 6:08 PM > > > > > To: Dai, Wei <wei....@intel.com>; Wang, Xiao W > > > > > <xiao.w.w...@intel.com> > > > > > Cc: dev@dpdk.org > > > > > Subject: RE: [PATCH v2 1/2] net/fm10k: convert to new Rx > > > > > offloads API > > > > > > > > > > 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 > Konstantin > > > > > Regards > > Qi > > > > > > > Konstantin > > > > > > > > > > > > > > > > > Regards > > > > > Qi
