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

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

Hi Ferruh,

On 2022-04-27 10:47:03 +0100, Ferruh Yigit wrote:
> On 4/27/2022 9:37 AM, Niklas Söderlund wrote:
> > 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.
> > 
> 
> It is not clear why it failed, patch looks nothing specific to Windows.
> I have triggered a new build (on top of next-net), please give ~15 minutes.

Thanks, it appears to have done the trick.

> 
> > 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?
> > 
> 
> The patchwork warning is to highlight new version of patches needs to be
> send as reply to previous version. This enables all versions are in same
> email thread, and this helps reviewer to see previous versions and
> comments/changes to previous versions easily. Also this makes possible to
> see all versions and history in one place in mail list archives.
> 
> There is nothing to do for this version, but please use 'git send-email',
> '--in-reply-to' option for new patches.
> 
> > 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.
> > 
> 
> The patch is not blocked for above reasons, it is in the queue (which is
> moving a little slow in this release for some operational reasons).

Thanks for this clarification on the status of the patch.

> 
> > 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