Re: [dpdk-dev] [PATCH v3 03/10] net/enic: heed the requested max Rx packet size

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

On 3/9/2018 3:51 PM, Ananyev, Konstantin wrote:
> 
> Hi everyone,
> 
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
>> Sent: Friday, March 9, 2018 3:04 PM
>> To: John Daley <johndale@cisco.com>
>> Cc: dev@dpdk.org; Hyong Youb Kim <hyonkim@cisco.com>
>> Subject: Re: [dpdk-dev] [PATCH v3 03/10] net/enic: heed the requested max Rx packet size
>>
>> On 3/8/2018 2:46 AM, John Daley wrote:
>>> From: Hyong Youb Kim <hyonkim@cisco.com>
>>>
>>> Currently, enic completely ignores the requested max Rx packet size
>>> (rxmode.max_rx_pkt_len). The desired behavior is that the NIC hardware
>>> drops packets larger than the requested size, even though they are
>>> still smaller than MTU.
>>
>> Your description looks reasonable but is there reason of two levels of limits,
>> max_rx_pkt_len and MTU, why not just use MTU. There is already a mail thread to
>> clarify max_rx_pkt_len [1].
>>
>> Is this work based on an application that uses max_rx_pkt_len and to make PMD
>> compatible with that application? If so we can continue with patch, but if the
>> patch is to implement DPDK properly I suggest postponing this until
>> max_rx_pkt_len clarified.
>>
>> [1]
>> https://dpdk.org/ml/archives/dev/2018-March/092178.html
> 
> I think there are quite a lot apps these days that might rely on setting MTU via
> rxmode.max_rx_pkt_len.
> I think we need to support them till we (ever) deprecate rxmode.max_rx_pkt_len.

Right. I was trying to save effort in case something changes related
max_rx_pkt_len, but since it is not clear yet, will continue with this patch.

> Konstantin
> 
>>
>>>
>>> Cisco VIC does not have such a feature. But, we can accomplish a
>>> similar (not same) effect by reducing the size of posted receive
>>> buffers. Packets larger than the posted size get truncated, and the
>>> receive handler drops them. This is also how the kernel enic driver
>>> enforces the Rx side MTU.
>>>
>>> This workaround works only when scatter mode is *not* used. When
>>> scatter is used, there is currently no way to support
>>> rxmode.max_rx_pkt_len, as the NIC always receives packets up to MTU.
>>>
>>> For posterity, add a copious amount of comments regarding the
>>> hardware's drop/receive behavior with respect to max/current MTU.
>>>
>>> Signed-off-by: Hyong Youb Kim <hyonkim@cisco.com>
>>> Reviewed-by: John Daley <johndale@cisco.com>
>>
>> <...>
>