Re: [PATCH v2] net/nfp: update how MAX MTU is read

["Niklas Söderlund" <niklas.soderlund@corigine.com>]

Hello,

I have a question about the Checks that ran on this patch in patchwork 
[1]. It appears the job ci/iol-x86_64-compile-testing, 
dpdk_mingw64_compile have failed on a Windows Server 2019 build. But the 
logs from the job appears to be incomplete as it contains only 19 lines 
of output and stops without an error in the configuration part of meson. 

The failure is only flagged as a warning and not as an error in 
patchwork, is it it possible that the job in question fails to capture 
all output or that it fails to complete sometimes?

What can we do to on our end to remedy this? My concern is that that the 
patch is blocked due to the warning and I'm unclear on how move forward, 
sorry if the case is that I'm just impatient.

1. https://patchwork.dpdk.org/project/dpdk/patch/20220420134638.24010-1-walter.heymans@corigine.com/

On 2022-04-20 15:46:39 +0200, Walter Heymans wrote:
> The 'max_rx_pktlen' value was previously read from hardware, which was
> set by the running firmware. This caused confusion due to different
> meanings of 'MAX_MTU'. This patch updates the 'max_rx_pktlen' to the
> maximum value that the NFP NIC can support. The 'max_mtu' value that is
> read from hardware, is assigned to the 'dev_info->max_mtu' variable.
> 
> If more layer 2 metadata must be used, the firmware can be updated to
> report a smaller 'max_mtu' value.
> 
> The constant defined for NFP_FRAME_SIZE_MAX is derived for the maximum
> supported buffer size of 10240, minus 136 bytes that is reserved by the
> hardware and another 56 bytes reserved for expansion in firmware. This
> results in a usable maximum packet length of 10048 bytes.
> 
> Signed-off-by: Walter Heymans <walter.heymans@corigine.com>
> Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
> Reviewed-by: Louis Peens <louis.peens@corigine.com>
> Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
> Reviewed-by: Richard Donkin <richard.donkin@corigine.com>
> ---
>  drivers/net/nfp/nfp_common.c | 11 ++++++++++-
>  drivers/net/nfp/nfp_common.h |  3 +++
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/nfp/nfp_common.c b/drivers/net/nfp/nfp_common.c
> index b26770dbfb..52fbda1a79 100644
> --- a/drivers/net/nfp/nfp_common.c
> +++ b/drivers/net/nfp/nfp_common.c
> @@ -692,7 +692,16 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>  	dev_info->max_rx_queues = (uint16_t)hw->max_rx_queues;
>  	dev_info->max_tx_queues = (uint16_t)hw->max_tx_queues;
>  	dev_info->min_rx_bufsize = RTE_ETHER_MIN_MTU;
> -	dev_info->max_rx_pktlen = hw->max_mtu;
> +	/*
> +	 * The maximum rx packet length (max_rx_pktlen) is set to the
> +	 * maximum supported frame size that the NFP can handle. This
> +	 * includes layer 2 headers, CRC and other metadata that can
> +	 * optionally be used.
> +	 * The maximum layer 3 MTU (max_mtu) is read from hardware,
> +	 * which was set by the firmware loaded onto the card.
> +	 */
> +	dev_info->max_rx_pktlen = NFP_FRAME_SIZE_MAX;
> +	dev_info->max_mtu = hw->max_mtu;
>  	/* Next should change when PF support is implemented */
>  	dev_info->max_mac_addrs = 1;
>  
> diff --git a/drivers/net/nfp/nfp_common.h b/drivers/net/nfp/nfp_common.h
> index 8b35fa119c..8db5ec23f8 100644
> --- a/drivers/net/nfp/nfp_common.h
> +++ b/drivers/net/nfp/nfp_common.h
> @@ -98,6 +98,9 @@ struct nfp_net_adapter;
>  /* Number of supported physical ports */
>  #define NFP_MAX_PHYPORTS	12
>  
> +/* Maximum supported NFP frame size (MTU + layer 2 headers) */
> +#define NFP_FRAME_SIZE_MAX	10048
> +
>  #include <linux/types.h>
>  #include <rte_io.h>
>  
> -- 
> 2.25.1
> 

-- 
Kind Regards,
Niklas Söderlund