Re: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

[Ferruh Yigit <ferruh.yigit@intel.com>]

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 <konstantin.ananyev@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wang, Xiao W <xiao.w.wang@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
>>
>> 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 <qi.z.zhang@intel.com>; Dai, Wei <wei.dai@intel.com>;
>>> Wang, Xiao W <xiao.w.wang@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,
>>>
>>>>>>>>>
>>>>>>>>> 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