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.heym...@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.heym...@corigine.com> > > > Signed-off-by: Niklas Söderlund <niklas.soderl...@corigine.com> > > > Reviewed-by: Louis Peens <louis.pe...@corigine.com> > > > Reviewed-by: Chaoyong He <chaoyong...@corigine.com> > > > Reviewed-by: Richard Donkin <richard.don...@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
