[v2] net/nfp: update how MAX MTU is read
Checks
Commit Message
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(-)
Comments
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
>
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.
> 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).
> 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
>>
>
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
> > >
> >
>
On 4/20/2022 2:46 PM, 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;
Hi Walter,
ethdev uses 'max_mtu' and 'max_rx_pktlen' to calculate the frame
overhead, like:
'overhead_len = max_rx_pktlen - max_mtu;'
In above change 'max_rx_pktlen' is hardcoded but 'max_mtu' is 'hw'
depended, can you confirm 'hw->max_mtu' will always have the frame
overhead as according above calculation?
> /* 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>
>
On 5/03/2022 9:05 PM, Ferruh Yigit wrote:
> On 4/20/2022 2:46 PM, 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;
>
> Hi Walter,
>
> ethdev uses 'max_mtu' and 'max_rx_pktlen' to calculate the frame
> overhead, like:
> 'overhead_len = max_rx_pktlen - max_mtu;'
>
> In above change 'max_rx_pktlen' is hardcoded but 'max_mtu' is 'hw'
> depended, can you confirm 'hw->max_mtu' will always have the frame
> overhead as according above calculation?
Hi Ferruh,
The 'max_rx_pktlen' is hardcoded to the maximum packet length that
the hardware can support. The 'hw->max_mtu' is read from hardware,
but it is a variable value, depending on the firmware running on the
card. The firmware sets this value to account for the maximum overhead
required. To answer you question, yes, this value should always be
available.
On 4/20/2022 2:46 PM, 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>
Applied to dpdk-next-net/main, thanks.
@@ -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;
@@ -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>