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

Ferruh Yigit ferruh.yigit at intel.com
Fri Mar 9 16:03:42 CET 2018


On 3/8/2018 2:46 AM, John Daley wrote:
> From: Hyong Youb Kim <hyonkim at 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

> 
> 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 at cisco.com>
> Reviewed-by: John Daley <johndale at cisco.com>

<...>



More information about the dev mailing list