[PATCH 1/1] doc: virtual function MTU settings has no meaning

[Stephen Hemminger]

On Mon, 28 Oct 2024 16:45:09 +0200
Viacheslav Ovsiienko <viacheslavo at nvidia.com> wrote:

> There is the mlx5 NIC limitations - configuring MTU
> for PCI Virtual Function has no meaning. The actual maximal
> packet size in VF's receiving is limited by MTU configured
> on the related PCI Physical Function, the DPDK datapath
> running over VF should be prepared to handle packets
> of this maximal size.
> 
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo at nvidia.com>
> ---
>  doc/guides/nics/mlx5.rst | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
> index 8d1a1311d4..c7dcb74da7 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -191,6 +191,13 @@ Limitations
>      - IPv4/TCP with CVLAN filtering
>      - L4 steering rules for port RSS of UDP, TCP and IP
>  
> +- PCI Virtual Function MTU:
> +
> +  Configuring MTU for PCI Virtual Function has no meaning.
> +  The actual maximal packet size in VF's receiving is limited by MTU configured
> +  on the related PCI Physical Function, the DPDK datapath running over VF should be
> +  prepared to handle packets of this maximal size.
> +

This is true of many drivers not just MLX5.

And it is generally true that Maximum Receive Unit (MRU) can
be larger than Maximum Transmit Unit (MTU).

I would rather see a more precise definition of MTU in DPDK show up
in ethdev documentation than sprinkling bits in each vendor driver.