[PATCH] ether: fix configure() to use a default for max_rx_pkt_len

Subsystems: library code, the rest

STALE1212d

29 messages, 11 authors, 2023-06-08 · open the first message on its own page

[PATCH] ether: fix configure() to use a default for max_rx_pkt_len

From: Andriy Berestovskyy <hidden>
Date: 2017-03-23 17:06:33 

At the moment rte_eth_dev_configure() behaves inconsistent:
 - for normal frames: out of range max_rx_pkt_len uses a default
 - for jumbo frames: out of range max_rx_pkt_len gives an error

This patch fixes this inconsistency by using a default value
for max_rx_pkt_len both for normal and jumbo frames.

Signed-off-by: Andriy Berestovskyy <redacted>
---
 lib/librte_ether/rte_ethdev.c | 20 +++++---------------
 lib/librte_ether/rte_ethdev.h |  6 +++++-
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index eb0a94a..f560051 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -856,21 +856,11 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
 	 * length is supported by the configured device.
 	 */
 	if (dev_conf->rxmode.jumbo_frame == 1) {
-		if (dev_conf->rxmode.max_rx_pkt_len >
-		    dev_info.max_rx_pktlen) {
-			RTE_PMD_DEBUG_TRACE("ethdev port_id=%d max_rx_pkt_len %u"
-				" > max valid value %u\n",
-				port_id,
-				(unsigned)dev_conf->rxmode.max_rx_pkt_len,
-				(unsigned)dev_info.max_rx_pktlen);
-			return -EINVAL;
-		} else if (dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN) {
-			RTE_PMD_DEBUG_TRACE("ethdev port_id=%d max_rx_pkt_len %u"
-				" < min valid value %u\n",
-				port_id,
-				(unsigned)dev_conf->rxmode.max_rx_pkt_len,
-				(unsigned)ETHER_MIN_LEN);
-			return -EINVAL;
+		if (dev_conf->rxmode.max_rx_pkt_len > dev_info.max_rx_pktlen ||
+			dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN) {
+			/* Use maximum frame size the NIC supports */
+			dev->data->dev_conf.rxmode.max_rx_pkt_len =
+							dev_info.max_rx_pktlen;
 		}
 	} else {
 		if (dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN ||
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 4be217c..2adfd77 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -349,7 +349,11 @@ enum rte_eth_tx_mq_mode {
 struct rte_eth_rxmode {
 	/** The multi-queue packet distribution mode to be used, e.g. RSS. */
 	enum rte_eth_rx_mq_mode mq_mode;
-	uint32_t max_rx_pkt_len;  /**< Only used if jumbo_frame enabled. */
+	/**
+	 * Desired maximum RX frame size. Too short or too long size will be
+	 * substituted by a default value.
+	 */
+	uint32_t max_rx_pkt_len;
 	uint16_t split_hdr_size;  /**< hdr buf size (header_split enabled).*/
 	__extension__
 	uint16_t header_split : 1, /**< Header Split enable. */
-- 
2.7.4

[PATCH v2] ether: use a default for max Rx frame size in configure()

From: Andriy Berestovskyy <hidden>
Date: 2017-03-24 11:52:23 

At the moment rte_eth_dev_configure() behaves inconsistent:
 - for normal frames: out of range max_rx_pkt_len uses a default
 - for jumbo frames: out of range max_rx_pkt_len gives an error

This patch fixes this inconsistency by using a default value
for max_rx_pkt_len both for normal and jumbo frames.

Signed-off-by: Andriy Berestovskyy <redacted>
---

Notes:
    v2 changes:
     - reword the commit title according to the check-git-log.sh

 lib/librte_ether/rte_ethdev.c | 20 +++++---------------
 lib/librte_ether/rte_ethdev.h |  6 +++++-
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index eb0a94a..f560051 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -856,21 +856,11 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
 	 * length is supported by the configured device.
 	 */
 	if (dev_conf->rxmode.jumbo_frame == 1) {
-		if (dev_conf->rxmode.max_rx_pkt_len >
-		    dev_info.max_rx_pktlen) {
-			RTE_PMD_DEBUG_TRACE("ethdev port_id=%d max_rx_pkt_len %u"
-				" > max valid value %u\n",
-				port_id,
-				(unsigned)dev_conf->rxmode.max_rx_pkt_len,
-				(unsigned)dev_info.max_rx_pktlen);
-			return -EINVAL;
-		} else if (dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN) {
-			RTE_PMD_DEBUG_TRACE("ethdev port_id=%d max_rx_pkt_len %u"
-				" < min valid value %u\n",
-				port_id,
-				(unsigned)dev_conf->rxmode.max_rx_pkt_len,
-				(unsigned)ETHER_MIN_LEN);
-			return -EINVAL;
+		if (dev_conf->rxmode.max_rx_pkt_len > dev_info.max_rx_pktlen ||
+			dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN) {
+			/* Use maximum frame size the NIC supports */
+			dev->data->dev_conf.rxmode.max_rx_pkt_len =
+							dev_info.max_rx_pktlen;
 		}
 	} else {
 		if (dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN ||
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 4be217c..2adfd77 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -349,7 +349,11 @@ enum rte_eth_tx_mq_mode {
 struct rte_eth_rxmode {
 	/** The multi-queue packet distribution mode to be used, e.g. RSS. */
 	enum rte_eth_rx_mq_mode mq_mode;
-	uint32_t max_rx_pkt_len;  /**< Only used if jumbo_frame enabled. */
+	/**
+	 * Desired maximum RX frame size. Too short or too long size will be
+	 * substituted by a default value.
+	 */
+	uint32_t max_rx_pkt_len;
 	uint16_t split_hdr_size;  /**< hdr buf size (header_split enabled).*/
 	__extension__
 	uint16_t header_split : 1, /**< Header Split enable. */
-- 
2.7.4

Re: [PATCH v2] ether: use a default for max Rx frame size in configure()

From: Yang, Qiming <hidden>
Date: 2017-03-27 06:16:17 

Hi, Andriy

I don't think this is a bug. Return errors when configure an invalid max_rx_pkt_len is suitable for this generic API.
rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_queue, uint16_t nb_tx_queue, const struct rte_eth_conf *eth_conf) 
is used to configure an Ethernet device as eth_conf demand. 
It's not suitable to give a default value in this function.

BRs,
Qiming
quoted hunk
-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Andriy
Berestovskyy
Sent: Friday, March 24, 2017 7:52 PM
To: Thomas Monjalon <redacted>
Cc: dev@dpdk.org
Subject: [dpdk-dev] [PATCH v2] ether: use a default for max Rx frame size in
configure()

At the moment behaves inconsistent:
 - for normal frames: out of range max_rx_pkt_len uses a default
 - for jumbo frames: out of range max_rx_pkt_len gives an error

This patch fixes this inconsistency by using a default value for
max_rx_pkt_len both for normal and jumbo frames.

Signed-off-by: Andriy Berestovskyy
[off-list ref]
---

Notes:
    v2 changes:
     - reword the commit title according to the check-git-log.sh

 lib/librte_ether/rte_ethdev.c | 20 +++++---------------
lib/librte_ether/rte_ethdev.h |  6 +++++-
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index eb0a94a..f560051 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -856,21 +856,11 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t
nb_rx_q, uint16_t nb_tx_q,
 	 * length is supported by the configured device.
 	 */
 	if (dev_conf->rxmode.jumbo_frame == 1) {
-		if (dev_conf->rxmode.max_rx_pkt_len >
-		    dev_info.max_rx_pktlen) {
-			RTE_PMD_DEBUG_TRACE("ethdev port_id=%d
max_rx_pkt_len %u"
-				" > max valid value %u\n",
-				port_id,
-				(unsigned)dev_conf-
quoted
rxmode.max_rx_pkt_len,
-				(unsigned)dev_info.max_rx_pktlen);
-			return -EINVAL;
-		} else if (dev_conf->rxmode.max_rx_pkt_len <
ETHER_MIN_LEN) {
-			RTE_PMD_DEBUG_TRACE("ethdev port_id=%d
max_rx_pkt_len %u"
-				" < min valid value %u\n",
-				port_id,
-				(unsigned)dev_conf-
quoted
rxmode.max_rx_pkt_len,
-				(unsigned)ETHER_MIN_LEN);
-			return -EINVAL;
+		if (dev_conf->rxmode.max_rx_pkt_len >
dev_info.max_rx_pktlen ||
+			dev_conf->rxmode.max_rx_pkt_len <
ETHER_MIN_LEN) {
+			/* Use maximum frame size the NIC supports */
+			dev->data->dev_conf.rxmode.max_rx_pkt_len =
+
	dev_info.max_rx_pktlen;
 		}
 	} else {
 		if (dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN
|| diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 4be217c..2adfd77 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -349,7 +349,11 @@ enum rte_eth_tx_mq_mode {  struct
rte_eth_rxmode {
 	/** The multi-queue packet distribution mode to be used, e.g. RSS.
*/
 	enum rte_eth_rx_mq_mode mq_mode;
-	uint32_t max_rx_pkt_len;  /**< Only used if jumbo_frame enabled.
*/
+	/**
+	 * Desired maximum RX frame size. Too short or too long size will be
+	 * substituted by a default value.
+	 */
+	uint32_t max_rx_pkt_len;
 	uint16_t split_hdr_size;  /**< hdr buf size (header_split enabled).*/
 	__extension__
 	uint16_t header_split : 1, /**< Header Split enable. */
--
2.7.4

Re: [PATCH v2] ether: use a default for max Rx frame size in configure()

From: Andriy Berestovskyy <hidden>
Date: 2017-03-27 08:38:25 

Hey Qiming,

On 27.03.2017 08:15, Yang, Qiming wrote:
I don't think this is a bug. Return errors when configure an invalid max_rx_pkt_len is suitable for this generic API.
It is not a bug, it is an inconsistency. At the moment we can set max_rx_pkt_len for normal frames and if it is out of range a default value will be used instead.

IMO we should expect the same behavior from the same function for the jumbo frames.

So at the moment we have:
jumbo == 0, max_rx_pkt_len == 0, result: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 1200, result: max_rx_pkt_len = 1200
jumbo == 1, max_rx_pkt_len == 0, result: error
jumbo == 1, max_rx_pkt_len == 9K, result: error or max_rx_pkt_len = 9K


It's not suitable to give a default value in this function.
We use a default value for normal frames at the moment. The comment:

uint32_t max_rx_pkt_len;  /**< Only used if jumbo_frame enabled. */

is obsolete and in fact we use max_rx_pkt_len both for jumbo and normal frames. So the patch clarifies this as well.


Regards,
Andriy

Re: [PATCH v2] ether: use a default for max Rx frame size in configure()

From: Thomas Monjalon <hidden>
Date: 2017-04-06 20:49:00 

2017-03-24 12:52, Andriy Berestovskyy:
At the moment rte_eth_dev_configure() behaves inconsistent:
 - for normal frames: out of range max_rx_pkt_len uses a default
 - for jumbo frames: out of range max_rx_pkt_len gives an error

This patch fixes this inconsistency by using a default value
for max_rx_pkt_len both for normal and jumbo frames.

Signed-off-by: Andriy Berestovskyy <redacted>
It is a bit strange to use the max value when the input is below the minimum.

Anyway, why not fixing it in the reverse way: returning error for
out of range of non-jumbo frames?
I am not sure setting a default value in the back of the caller is really
a good behaviour.

Re: [PATCH v2] ether: use a default for max Rx frame size in configure()

From: Andriy Berestovskyy <hidden>
Date: 2017-04-07 08:10:03 

Hi Thomas,

On 06.04.2017 22:48, Thomas Monjalon wrote:
Anyway, why not fixing it in the reverse way: returning error for
out of range of non-jumbo frames?
I guess we need to fix most of the examples then, since most of them just pass 0 for normal frames. And there is no default for jumbo frames, so an app must first get this info from the NIC...


I am not sure setting a default value in the back of the caller is really
a good behaviour.
From app perspective, any working default is better that a non-working app, which you have to fix and recompile on each PMD/platform.


What if we use 0 for a default value both for normal and jumbo frames (i.e. ETHER_MAX_LEN and dev_info.max_rx_pktlen) and an error if user passed a non-zero max_rx_pkt_len?

It will make it consistent, we will not need to fix the existing apps and we will have a default both for normal and jumbo frames. Win-win? ;)


Andriy

Re: [PATCH v2] ether: use a default for max Rx frame size in configure()

From: Bruce Richardson <hidden>
Date: 2017-04-07 08:24:12 

On Mon, Mar 27, 2017 at 10:38:13AM +0200, Andriy Berestovskyy wrote:
Hey Qiming,

On 27.03.2017 08:15, Yang, Qiming wrote:
quoted
I don't think this is a bug. Return errors when configure an invalid max_rx_pkt_len is suitable for this generic API.
It is not a bug, it is an inconsistency. At the moment we can set
max_rx_pkt_len for normal frames and if it is out of range a default value
will be used instead.

IMO we should expect the same behavior from the same function for the jumbo
frames.

So at the moment we have:
jumbo == 0, max_rx_pkt_len == 0, result: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 1200, result: max_rx_pkt_len = 1200
Is this really the case right now. My understanding was that when jumbo
== 0 max_rx_pkt_len is ignored. At least on Intel NICS, I believe the
max_rx_pkt_len is always 1518 unless jumbo frame support is explicitly
enabled. [Perhaps the driver maintainers can confirm this for me.]

Regards,
/Bruce

Re: [PATCH v2] ether: use a default for max Rx frame size in configure()

From: Thomas Monjalon <hidden>
Date: 2017-04-07 08:34:50 

2017-04-07 10:09, Andriy Berestovskyy:
Hi Thomas,

On 06.04.2017 22:48, Thomas Monjalon wrote:
quoted
Anyway, why not fixing it in the reverse way: returning error for
out of range of non-jumbo frames?
I guess we need to fix most of the examples then, since most of them 
just pass 0 for normal frames. And there is no default for jumbo frames, 
so an app must first get this info from the NIC...
Yes, I would vote to return the NIC capabilities to the app.
quoted
I am not sure setting a default value in the back of the caller is really
a good behaviour.
 From app perspective, any working default is better that a non-working 
app, which you have to fix and recompile on each PMD/platform.
Right
That's why there should be a capabilities API for this need.

What if we use 0 for a default value both for normal and jumbo frames 
(i.e. ETHER_MAX_LEN and dev_info.max_rx_pktlen) and an error if user 
passed a non-zero max_rx_pkt_len?
We can set the right default value if the app input is 0,
as a special case.
For any other value, we must try to set it or return an error.

It will make it consistent, we will not need to fix the existing apps 
and we will have a default both for normal and jumbo frames. Win-win? ;)

Re: [PATCH v2] ether: use a default for max Rx frame size in configure()

From: Andriy Berestovskyy <hidden>
Date: 2017-04-07 08:55:48 

On 07.04.2017 10:34, Thomas Monjalon wrote:
We can set the right default value if the app input is 0,
as a special case.
For any other value, we must try to set it or return an error.
Right, I will resend the patch.

Andriy

[PATCH v3] ether: use a default for max Rx frame size in configure()

From: Andriy Berestovskyy <hidden>
Date: 2017-04-07 11:02:35 

At the moment rte_eth_dev_configure() behaves inconsistent:
 - for normal frames: zero max_rx_pkt_len uses a default
 - for jumbo frames: zero max_rx_pkt_len gives an error

This patch fixes this inconsistency by using a default value
if max_rx_pkt_len is zero both for normal and jumbo frames.

Signed-off-by: Andriy Berestovskyy <redacted>
---

Notes:
    v3 changes:
     - use a default only if max_rx_pkt_len is zero
    
    v2 changes:
     - reword the commit title according to the check-git-log.sh

 lib/librte_ether/rte_ethdev.c | 23 ++++++++++++-----------
 lib/librte_ether/rte_ethdev.h |  2 +-
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 4e1e6dc..2700c69 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -790,6 +790,7 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
 {
 	struct rte_eth_dev *dev;
 	struct rte_eth_dev_info dev_info;
+	uint32_t max_len;
 	int diag;
 
 	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
@@ -858,17 +859,23 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
 	}
 
 	/*
-	 * If jumbo frames are enabled, check that the maximum RX packet
-	 * length is supported by the configured device.
+	 * Check that the maximum RX packet length is supported
+	 * by the configured device.
 	 */
 	if (dev_conf->rxmode.jumbo_frame == 1) {
-		if (dev_conf->rxmode.max_rx_pkt_len >
-		    dev_info.max_rx_pktlen) {
+		max_len = dev_info.max_rx_pktlen;
+	} else {
+		max_len = ETHER_MAX_LEN;
+	}
+	if (dev_conf->rxmode.max_rx_pkt_len == 0) {
+		dev->data->dev_conf.rxmode.max_rx_pkt_len = max_len;
+	} else {
+		if (dev_conf->rxmode.max_rx_pkt_len > max_len) {
 			RTE_PMD_DEBUG_TRACE("ethdev port_id=%d max_rx_pkt_len %u"
 				" > max valid value %u\n",
 				port_id,
 				(unsigned)dev_conf->rxmode.max_rx_pkt_len,
-				(unsigned)dev_info.max_rx_pktlen);
+				(unsigned int)max_len);
 			return -EINVAL;
 		} else if (dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN) {
 			RTE_PMD_DEBUG_TRACE("ethdev port_id=%d max_rx_pkt_len %u"
@@ -878,12 +885,6 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
 				(unsigned)ETHER_MIN_LEN);
 			return -EINVAL;
 		}
-	} else {
-		if (dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN ||
-			dev_conf->rxmode.max_rx_pkt_len > ETHER_MAX_LEN)
-			/* Use default value */
-			dev->data->dev_conf.rxmode.max_rx_pkt_len =
-							ETHER_MAX_LEN;
 	}
 
 	/*
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index d072538..ea760dc 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -349,7 +349,7 @@ enum rte_eth_tx_mq_mode {
 struct rte_eth_rxmode {
 	/** The multi-queue packet distribution mode to be used, e.g. RSS. */
 	enum rte_eth_rx_mq_mode mq_mode;
-	uint32_t max_rx_pkt_len;  /**< Only used if jumbo_frame enabled. */
+	uint32_t max_rx_pkt_len;  /**< If zero, use a default packet length. */
 	uint16_t split_hdr_size;  /**< hdr buf size (header_split enabled).*/
 	__extension__
 	uint16_t header_split : 1, /**< Header Split enable. */
-- 
2.7.4

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Thomas Monjalon <hidden>
Date: 2017-04-07 12:15:49 

2017-04-07 13:02, Andriy Berestovskyy:
At the moment rte_eth_dev_configure() behaves inconsistent:
 - for normal frames: zero max_rx_pkt_len uses a default
 - for jumbo frames: zero max_rx_pkt_len gives an error

This patch fixes this inconsistency by using a default value
if max_rx_pkt_len is zero both for normal and jumbo frames.

Signed-off-by: Andriy Berestovskyy <redacted>
---

Notes:
    v3 changes:
     - use a default only if max_rx_pkt_len is zero
Looks good.

Acked-by: Thomas Monjalon <redacted>

It is a small API change but it is fixing an inconsistency,
so I think it can be integrated in 17.05-rc2 as is.
Any different opinion?

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Bruce Richardson <hidden>
Date: 2017-04-07 12:30:01 

On Fri, Apr 07, 2017 at 02:15:47PM +0200, Thomas Monjalon wrote:
2017-04-07 13:02, Andriy Berestovskyy:
quoted
At the moment rte_eth_dev_configure() behaves inconsistent:
 - for normal frames: zero max_rx_pkt_len uses a default
 - for jumbo frames: zero max_rx_pkt_len gives an error

This patch fixes this inconsistency by using a default value
if max_rx_pkt_len is zero both for normal and jumbo frames.

Signed-off-by: Andriy Berestovskyy <redacted>
---

Notes:
    v3 changes:
     - use a default only if max_rx_pkt_len is zero
Looks good.

Acked-by: Thomas Monjalon <redacted>

It is a small API change but it is fixing an inconsistency,
so I think it can be integrated in 17.05-rc2 as is.
Any different opinion?
Is this entirely hidden from drivers? As I said previously, I believe
NICs using ixgbe/i40e etc. only use the frame size value when the jumbo
frame flag is set. That may lead to further inconsistent behaviour unless
all NICs are set up to behave as expected too.

/Bruce

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Andriy Berestovskyy <hidden>
Date: 2017-04-07 14:18:52 

Hey Bruce,

On 07.04.2017 14:29, Bruce Richardson wrote:
Is this entirely hidden from drivers? As I said previously, I believe
NICs using ixgbe/i40e etc. only use the frame size value when the jumbo
frame flag is set. That may lead to further inconsistent behaviour unless
all NICs are set up to behave as expected too.
You are right. If we take just Intel PMDs: some use the max_rx_pkt_len only for jumbo frames (ixgbe), some always (i40) and some never (fm10k).

What if we add to the max_rx_pkt_len description: "the effective maximum RX frame size depends on PMD, please refer the PMD guide for the details"?

So with this patch we make rte_eth_dev_configure() clear and later PMDs might change or clarify their limitations in the NIC guides.

Andriy

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Thomas Monjalon <hidden>
Date: 2017-04-07 14:47:46 

2017-04-07 16:18, Andriy Berestovskyy:
Hey Bruce,

On 07.04.2017 14:29, Bruce Richardson wrote:
quoted
Is this entirely hidden from drivers? As I said previously, I believe
NICs using ixgbe/i40e etc. only use the frame size value when the jumbo
frame flag is set. That may lead to further inconsistent behaviour unless
all NICs are set up to behave as expected too.
You are right. If we take just Intel PMDs: some use the max_rx_pkt_len 
only for jumbo frames (ixgbe), some always (i40) and some never (fm10k).

What if we add to the max_rx_pkt_len description: "the effective maximum 
RX frame size depends on PMD, please refer the PMD guide for the details"?
I think the problem is not in the documentation but in the implementations
which should be more consistent.

So with this patch we make rte_eth_dev_configure() clear and later PMDs 
might change or clarify their limitations in the NIC guides.
If I understand well, the inconsistency between drivers was already an
issue before your patch.
Your patch fixes an inconsistency in ethdev without fixing the drivers.
We need to know if it is a good first step and if the drivers can be
fixed later.

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Andriy Berestovskyy <hidden>
Date: 2017-04-07 15:27:24 

Hey Thomas,

On 07.04.2017 16:47, Thomas Monjalon wrote:
quoted
What if we add to the max_rx_pkt_len description: "the effective maximum
RX frame size depends on PMD, please refer the PMD guide for the details"?
I think the problem is not in the documentation but in the implementations
which should be more consistent.
The hardware is different, there is not much we can do about it. Nevertheless, we can fix the false comment and have a default for the jumbos, which is beneficial for the apps/examples.


If I understand well, the inconsistency between drivers was already an
issue before your patch.
Your patch fixes an inconsistency in ethdev without fixing the drivers.
We need to know if it is a good first step and if the drivers can be
fixed later.
Thomas, some of the examples use a hard-coded jumbo frame size, which is too big for the underlaying PMDs, so those examples fail. The plan was to fix them all with this commit in ethdev but I am not sure now you are to accept the change.

It is important for us to have those examples working in the upcoming release, do you think it is better to send fixes for those examples instead of this commit then?


Andriy

[PATCH 1/3] examples/ip_fragmentation: limit max frame size

From: Andriy Berestovskyy <hidden>
Date: 2017-04-10 14:31:08 

Some PMDs do not support 9,5K jumbo frames, so the example fails.
Limit the frame size to the maximum supported by the underlying NIC.

Signed-off-by: Andriy Berestovskyy <redacted>
---
 examples/ip_fragmentation/main.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/examples/ip_fragmentation/main.c b/examples/ip_fragmentation/main.c
index 8d2ec43..31499c3 100644
--- a/examples/ip_fragmentation/main.c
+++ b/examples/ip_fragmentation/main.c
@@ -168,7 +168,7 @@ struct lcore_queue_conf {
 } __rte_cache_aligned;
 struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE];
 
-static const struct rte_eth_conf port_conf = {
+static struct rte_eth_conf port_conf = {
 	.rxmode = {
 		.max_rx_pkt_len = JUMBO_FRAME_MAX_SIZE,
 		.split_hdr_size = 0,
@@ -915,6 +915,11 @@ main(int argc, char **argv)
 
 		qconf = &lcore_queue_conf[rx_lcore_id];
 
+		/* limit the frame size to the maximum supported by NIC */
+		rte_eth_dev_info_get(portid, &dev_info);
+		port_conf.rxmode.max_rx_pkt_len = RTE_MIN(
+		    dev_info.max_rx_pktlen, port_conf.rxmode.max_rx_pkt_len);
+
 		/* get the lcore_id for this port */
 		while (rte_lcore_is_enabled(rx_lcore_id) == 0 ||
 		       qconf->n_rx_queue == (unsigned)rx_queue_per_lcore) {
@@ -980,7 +985,6 @@ main(int argc, char **argv)
 			printf("txq=%u,%d ", lcore_id, queueid);
 			fflush(stdout);
 
-			rte_eth_dev_info_get(portid, &dev_info);
 			txconf = &dev_info.default_txconf;
 			txconf->txq_flags = 0;
 			ret = rte_eth_tx_queue_setup(portid, queueid, nb_txd,
-- 
2.7.4

[PATCH 2/3] examples/ip_reassembly: limit max frame size

From: Andriy Berestovskyy <hidden>
Date: 2017-04-10 14:31:10 

Some PMDs do not support 9,5K jumbo frames, so the example fails.
Limit the frame size to the maximum supported by the underlying NIC.

Signed-off-by: Andriy Berestovskyy <redacted>
---
 examples/ip_reassembly/main.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/examples/ip_reassembly/main.c b/examples/ip_reassembly/main.c
index b641576..257881c 100644
--- a/examples/ip_reassembly/main.c
+++ b/examples/ip_reassembly/main.c
@@ -1063,6 +1063,11 @@ main(int argc, char **argv)
 
 		qconf = &lcore_queue_conf[rx_lcore_id];
 
+		/* limit the frame size to the maximum supported by NIC */
+		rte_eth_dev_info_get(portid, &dev_info);
+		port_conf.rxmode.max_rx_pkt_len = RTE_MIN(
+		    dev_info.max_rx_pktlen, port_conf.rxmode.max_rx_pkt_len);
+
 		/* get the lcore_id for this port */
 		while (rte_lcore_is_enabled(rx_lcore_id) == 0 ||
 			   qconf->n_rx_queue == (unsigned)rx_queue_per_lcore) {
@@ -1129,7 +1134,6 @@ main(int argc, char **argv)
 			printf("txq=%u,%d,%d ", lcore_id, queueid, socket);
 			fflush(stdout);
 
-			rte_eth_dev_info_get(portid, &dev_info);
 			txconf = &dev_info.default_txconf;
 			txconf->txq_flags = 0;
 
-- 
2.7.4

[PATCH 3/3] examples/ipv4_multicast: limit max frame size

From: Andriy Berestovskyy <hidden>
Date: 2017-04-10 14:31:11 

Some PMDs do not support 9,5K jumbo frames, so the example fails.
Limit the frame size to the maximum supported by the underlying NIC.

Signed-off-by: Andriy Berestovskyy <redacted>
---
 examples/ipv4_multicast/main.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/examples/ipv4_multicast/main.c b/examples/ipv4_multicast/main.c
index b681f8e..b4bd699 100644
--- a/examples/ipv4_multicast/main.c
+++ b/examples/ipv4_multicast/main.c
@@ -137,7 +137,7 @@ struct lcore_queue_conf {
 } __rte_cache_aligned;
 static struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE];
 
-static const struct rte_eth_conf port_conf = {
+static struct rte_eth_conf port_conf = {
 	.rxmode = {
 		.max_rx_pkt_len = JUMBO_FRAME_MAX_SIZE,
 		.split_hdr_size = 0,
@@ -725,6 +725,11 @@ main(int argc, char **argv)
 
 		qconf = &lcore_queue_conf[rx_lcore_id];
 
+		/* limit the frame size to the maximum supported by NIC */
+		rte_eth_dev_info_get(portid, &dev_info);
+		port_conf.rxmode.max_rx_pkt_len = RTE_MIN(
+		    dev_info.max_rx_pktlen, port_conf.rxmode.max_rx_pkt_len);
+
 		/* get the lcore_id for this port */
 		while (rte_lcore_is_enabled(rx_lcore_id) == 0 ||
 		       qconf->n_rx_queue == (unsigned)rx_queue_per_lcore) {
@@ -777,7 +782,6 @@ main(int argc, char **argv)
 			printf("txq=%u,%hu ", lcore_id, queueid);
 			fflush(stdout);
 
-			rte_eth_dev_info_get(portid, &dev_info);
 			txconf = &dev_info.default_txconf;
 			txconf->txq_flags = 0;
 			ret = rte_eth_tx_queue_setup(portid, queueid, nb_txd,
-- 
2.7.4

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Thomas Monjalon <hidden>
Date: 2017-04-20 22:25:18 

07/04/2017 17:27, Andriy Berestovskyy:
Hey Thomas,

On 07.04.2017 16:47, Thomas Monjalon wrote:
quoted
quoted
What if we add to the max_rx_pkt_len description: "the effective maximum
RX frame size depends on PMD, please refer the PMD guide for the
details"?
I think the problem is not in the documentation but in the implementations
which should be more consistent.
The hardware is different, there is not much we can do about it.
We can return an error if the max_rx_pkt_len cannot be set in the NIC.

Nevertheless, we can fix the false comment and have a default for the
jumbos, which is beneficial for the apps/examples.
The examples are using a hardcoded value, so they need to be fixed anyway.
quoted
If I understand well, the inconsistency between drivers was already an
issue before your patch.
Your patch fixes an inconsistency in ethdev without fixing the drivers.
We need to know if it is a good first step and if the drivers can be
fixed later.
Thomas, some of the examples use a hard-coded jumbo frame size, which is
too big for the underlaying PMDs, so those examples fail. The plan was
to fix them all with this commit in ethdev but I am not sure now you are
to accept the change.
This ethdev patch is about a behaviour change of the API.
It is about considering 0 as a request for default value
and return an error if a value cannot be set.
It will require more agreements and changes in the drivers
for returning an error where appropriate.

It is important for us to have those examples working in the upcoming
release, do you think it is better to send fixes for those examples
instead of this commit then?
The examples can be improved independently of this patch.

Re: [PATCH 1/3] examples/ip_fragmentation: limit max frame size

From: Thomas Monjalon <hidden>
Date: 2017-04-21 00:21:48 

10/04/2017 16:30, Andriy Berestovskyy:
Some PMDs do not support 9,5K jumbo frames, so the example fails.
Limit the frame size to the maximum supported by the underlying NIC.

Signed-off-by: Andriy Berestovskyy <redacted>
Series squashed and applied, thanks

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Andriy Berestovskyy <hidden>
Date: 2017-04-24 14:50:48 

Hey Thomas,

On 21.04.2017 00:25, Thomas Monjalon wrote:
quoted
The hardware is different, there is not much we can do about it.
We can return an error if the max_rx_pkt_len cannot be set in the NIC.
Yes, we pass the value to the PMD, which might check the value and return an error.
quoted
Nevertheless, we can fix the false comment and have a default for the
jumbos, which is beneficial for the apps/examples.
The examples are using a hardcoded value, so they need to be fixed
anyway.
We might change the hardcoded values to zeros once the patch is in. This will make the examples a bit more clear.


This ethdev patch is about a behaviour change of the API.
The behaviour was not documented, so IMO it is not an issue.


It is about considering 0 as a request for default value
and return an error if a value cannot be set.
Right.


It will require more agreements and changes in the drivers
for returning an error where appropriate.
IMO the changes are transparent for the PMDs (please see below), but it might affect some applications. Here is the change in API behaviour:

Before the patch:
jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 10, RESULT: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 0, max_rx_pkt_len == 9K, RESULT: max_rx_pkt_len = ETHER_MAX_LEN

jumbo == 1, max_rx_pkt_len == 0, RESULT: ERROR
jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR
jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K
jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR


After the patch:
jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 10, RESULT: ERROR (changed)
jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 0, max_rx_pkt_len == 9K, RESULT: ERROR (changed)

jumbo == 1, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = dev_info()
jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR
jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K
jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR

Only the apps which requested too small or too big normal frames will be affected. In most cases it will be rather an error in the app...


Also I have looked through all the PMDs to confirm they are not affected. Here is the summary:

af_packet
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETH_FRAME_LEN (1514)

ark
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETH_FRAME_LEN (16K - 128)

avp
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = avp->max_rx_pkt_len
rx_queue_setup() uses max_rx_pkt_len for scattering

bnx2x
configure() uses max_rx_pkt_len to set internal mtu
info() returns max_rx_pktlen = BNX2X_MAX_RX_PKT_LEN (15872)

bnxt
configure() uses max_rx_pkt_len to set internal mtu
info() returns max_rx_pktlen = BNXT_MAX_MTU + ETHER_HDR_LEN + ETHER_CRC_LEN + VLAN_TAG_SIZE (9000 + 14 + 4 + 4)

bonding
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = internals->candidate_max_rx_pktlen or ETHER_MAX_JUMBO_FRAME_LEN (0x3F00)

cxgbe
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = CXGBE_MAX_RX_PKTLEN (9000 + 14 + 4)
rx_queue_setup() checks max_rx_pkt_len boundaries

dpaa2
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = DPAA2_MAX_RX_PKT_LEN (10240)

e1000 (em)
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = em_get_max_pktlen() (0x2412, 0x1000, 1518, 0x3f00, depends on model)

e1000 (igb)
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 0x3fff
start() writes max_rx_pkt_len to HW for jumbo frames only
start() uses max_rx_pkt_len for scattering

ena
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = adapter->max_mtu
start() checks max_rx_pkt_len boundaries

enic
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = enic->max_mtu + 14 + 4

fm10k
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = FM10K_MAX_PKT_SIZE (15 * 1024)
start() uses max_rx_pkt_len for scattering

i40e
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = I40E_FRAME_SIZE_MAX (9728)
rx_queue_config() checks max_rx_pkt_len boundaries

ixgbe
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 15872 (9728 for vf)
start() writes max_rx_pkt_len to HW for jumbo frames only
start() uses max_rx_pkt_len for scattering

kni
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = UINT32_MAX

liquidio
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = LIO_MAX_RX_PKTLEN (64K)
start() checks max_rx_pkt_len boundaries

mlx4
configure() uses max_rx_pkt_len for scattering
info() returns max_rx_pktlen = 65536

mlx5
configure() uses max_rx_pkt_len for scattering
info() returns max_rx_pktlen = 65536

nfp
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = hw->mtu

null
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

pcap
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

qede
configure() uses max_rx_pkt_len for scattering + internal data
info() returns max_rx_pktlen = ETH_TX_MAX_NON_LSO_PKT_LEN (9700 - 4 - 4 - 12 - 8)

ring
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

sfc
configure() uses max_rx_pkt_len to set internal data
info() returns max_rx_pktlen = EFX_MAC_PDU_MAX (9202 + 14 + 4 + 4 + 16)

szedata2
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

tap
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETHER_MAX_VLAN_FRAME_LEN (1518 + 4)

thunderx
configure() uses max_rx_pkt_len for scattering + sets internal mtu
info() returns max_rx_pktlen = NIC_HW_MAX_FRS (9200)

vhost
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

virtio
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN (9728U)

vmxnet3
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 16384;

xenvirt
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 2048


Regards,
Andriy

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Thomas Monjalon <hidden>
Date: 2017-07-31 22:33:07 

We are missing some comments about this proposal.

24/04/2017 16:50, Andriy Berestovskyy:
Hey Thomas,

On 21.04.2017 00:25, Thomas Monjalon wrote:
quoted
quoted
The hardware is different, there is not much we can do about it.
We can return an error if the max_rx_pkt_len cannot be set in the NIC.
Yes, we pass the value to the PMD, which might check the value and 
return an error.

 >> Nevertheless, we can fix the false comment and have a default for the
 >> jumbos, which is beneficial for the apps/examples.
 >
 > The examples are using a hardcoded value, so they need to be fixed
 > anyway.

We might change the hardcoded values to zeros once the patch is in. This 
will make the examples a bit more clear.
quoted
This ethdev patch is about a behaviour change of the API.
The behaviour was not documented, so IMO it is not an issue.
quoted
It is about considering 0 as a request for default value
and return an error if a value cannot be set.
Right.
quoted
It will require more agreements and changes in the drivers
for returning an error where appropriate.
IMO the changes are transparent for the PMDs (please see below), but it 
might affect some applications. Here is the change in API behaviour:

Before the patch:
jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 10, RESULT: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 0, max_rx_pkt_len == 9K, RESULT: max_rx_pkt_len = ETHER_MAX_LEN

jumbo == 1, max_rx_pkt_len == 0, RESULT: ERROR
jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR
jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K
jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR


After the patch:
jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 10, RESULT: ERROR (changed)
jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 0, max_rx_pkt_len == 9K, RESULT: ERROR (changed)

jumbo == 1, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = dev_info()
jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR
jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K
jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR

Only the apps which requested too small or too big normal frames will be 
affected. In most cases it will be rather an error in the app...


Also I have looked through all the PMDs to confirm they are not 
affected. Here is the summary:

af_packet
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETH_FRAME_LEN (1514)

ark
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETH_FRAME_LEN (16K - 128)

avp
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = avp->max_rx_pkt_len
rx_queue_setup() uses max_rx_pkt_len for scattering

bnx2x
configure() uses max_rx_pkt_len to set internal mtu
info() returns max_rx_pktlen = BNX2X_MAX_RX_PKT_LEN (15872)

bnxt
configure() uses max_rx_pkt_len to set internal mtu
info() returns max_rx_pktlen = BNXT_MAX_MTU + ETHER_HDR_LEN + 
ETHER_CRC_LEN + VLAN_TAG_SIZE (9000 + 14 + 4 + 4)

bonding
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = internals->candidate_max_rx_pktlen or 
ETHER_MAX_JUMBO_FRAME_LEN (0x3F00)

cxgbe
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = CXGBE_MAX_RX_PKTLEN (9000 + 14 + 4)
rx_queue_setup() checks max_rx_pkt_len boundaries

dpaa2
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = DPAA2_MAX_RX_PKT_LEN (10240)

e1000 (em)
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = em_get_max_pktlen() (0x2412, 0x1000, 
1518, 0x3f00, depends on model)

e1000 (igb)
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 0x3fff
start() writes max_rx_pkt_len to HW for jumbo frames only
start() uses max_rx_pkt_len for scattering

ena
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = adapter->max_mtu
start() checks max_rx_pkt_len boundaries

enic
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = enic->max_mtu + 14 + 4

fm10k
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = FM10K_MAX_PKT_SIZE (15 * 1024)
start() uses max_rx_pkt_len for scattering

i40e
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = I40E_FRAME_SIZE_MAX (9728)
rx_queue_config() checks max_rx_pkt_len boundaries

ixgbe
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 15872 (9728 for vf)
start() writes max_rx_pkt_len to HW for jumbo frames only
start() uses max_rx_pkt_len for scattering

kni
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = UINT32_MAX

liquidio
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = LIO_MAX_RX_PKTLEN (64K)
start() checks max_rx_pkt_len boundaries

mlx4
configure() uses max_rx_pkt_len for scattering
info() returns max_rx_pktlen = 65536

mlx5
configure() uses max_rx_pkt_len for scattering
info() returns max_rx_pktlen = 65536

nfp
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = hw->mtu

null
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

pcap
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

qede
configure() uses max_rx_pkt_len for scattering + internal data
info() returns max_rx_pktlen = ETH_TX_MAX_NON_LSO_PKT_LEN (9700 - 4 - 4 
- 12 - 8)

ring
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

sfc
configure() uses max_rx_pkt_len to set internal data
info() returns max_rx_pktlen = EFX_MAC_PDU_MAX (9202 + 14 + 4 + 4 + 16)

szedata2
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

tap
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETHER_MAX_VLAN_FRAME_LEN (1518 + 4)

thunderx
configure() uses max_rx_pkt_len for scattering + sets internal mtu
info() returns max_rx_pktlen = NIC_HW_MAX_FRS (9200)

vhost
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

virtio
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN (9728U)

vmxnet3
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 16384;

xenvirt
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 2048


Regards,
Andriy

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Thomas Monjalon <hidden>
Date: 2018-05-22 22:30:58 

This proposal had no conclusion.
The examples have been fixed:
	http://dpdk.org/commit/5e470a6654

But there is still an inconsistency in the API:
"
 - for normal frames: zero max_rx_pkt_len uses a default
 - for jumbo frames: zero max_rx_pkt_len gives an error
"


01/08/2017 00:33, Thomas Monjalon:
We are missing some comments about this proposal.

24/04/2017 16:50, Andriy Berestovskyy:
quoted
Hey Thomas,

On 21.04.2017 00:25, Thomas Monjalon wrote:
quoted
quoted
The hardware is different, there is not much we can do about it.
We can return an error if the max_rx_pkt_len cannot be set in the NIC.
Yes, we pass the value to the PMD, which might check the value and 
return an error.

 >> Nevertheless, we can fix the false comment and have a default for the
 >> jumbos, which is beneficial for the apps/examples.
 >
 > The examples are using a hardcoded value, so they need to be fixed
 > anyway.

We might change the hardcoded values to zeros once the patch is in. This 
will make the examples a bit more clear.
quoted
This ethdev patch is about a behaviour change of the API.
The behaviour was not documented, so IMO it is not an issue.
quoted
It is about considering 0 as a request for default value
and return an error if a value cannot be set.
Right.
quoted
It will require more agreements and changes in the drivers
for returning an error where appropriate.
IMO the changes are transparent for the PMDs (please see below), but it 
might affect some applications. Here is the change in API behaviour:

Before the patch:
jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 10, RESULT: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 0, max_rx_pkt_len == 9K, RESULT: max_rx_pkt_len = ETHER_MAX_LEN

jumbo == 1, max_rx_pkt_len == 0, RESULT: ERROR
jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR
jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K
jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR


After the patch:
jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN
jumbo == 0, max_rx_pkt_len == 10, RESULT: ERROR (changed)
jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 0, max_rx_pkt_len == 9K, RESULT: ERROR (changed)

jumbo == 1, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = dev_info()
jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR
jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200
jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K
jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR

Only the apps which requested too small or too big normal frames will be 
affected. In most cases it will be rather an error in the app...


Also I have looked through all the PMDs to confirm they are not 
affected. Here is the summary:

af_packet
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETH_FRAME_LEN (1514)

ark
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETH_FRAME_LEN (16K - 128)

avp
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = avp->max_rx_pkt_len
rx_queue_setup() uses max_rx_pkt_len for scattering

bnx2x
configure() uses max_rx_pkt_len to set internal mtu
info() returns max_rx_pktlen = BNX2X_MAX_RX_PKT_LEN (15872)

bnxt
configure() uses max_rx_pkt_len to set internal mtu
info() returns max_rx_pktlen = BNXT_MAX_MTU + ETHER_HDR_LEN + 
ETHER_CRC_LEN + VLAN_TAG_SIZE (9000 + 14 + 4 + 4)

bonding
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = internals->candidate_max_rx_pktlen or 
ETHER_MAX_JUMBO_FRAME_LEN (0x3F00)

cxgbe
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = CXGBE_MAX_RX_PKTLEN (9000 + 14 + 4)
rx_queue_setup() checks max_rx_pkt_len boundaries

dpaa2
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = DPAA2_MAX_RX_PKT_LEN (10240)

e1000 (em)
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = em_get_max_pktlen() (0x2412, 0x1000, 
1518, 0x3f00, depends on model)

e1000 (igb)
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 0x3fff
start() writes max_rx_pkt_len to HW for jumbo frames only
start() uses max_rx_pkt_len for scattering

ena
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = adapter->max_mtu
start() checks max_rx_pkt_len boundaries

enic
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = enic->max_mtu + 14 + 4

fm10k
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = FM10K_MAX_PKT_SIZE (15 * 1024)
start() uses max_rx_pkt_len for scattering

i40e
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = I40E_FRAME_SIZE_MAX (9728)
rx_queue_config() checks max_rx_pkt_len boundaries

ixgbe
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 15872 (9728 for vf)
start() writes max_rx_pkt_len to HW for jumbo frames only
start() uses max_rx_pkt_len for scattering

kni
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = UINT32_MAX

liquidio
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = LIO_MAX_RX_PKTLEN (64K)
start() checks max_rx_pkt_len boundaries

mlx4
configure() uses max_rx_pkt_len for scattering
info() returns max_rx_pktlen = 65536

mlx5
configure() uses max_rx_pkt_len for scattering
info() returns max_rx_pktlen = 65536

nfp
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = hw->mtu

null
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

pcap
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

qede
configure() uses max_rx_pkt_len for scattering + internal data
info() returns max_rx_pktlen = ETH_TX_MAX_NON_LSO_PKT_LEN (9700 - 4 - 4 
- 12 - 8)

ring
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

sfc
configure() uses max_rx_pkt_len to set internal data
info() returns max_rx_pktlen = EFX_MAC_PDU_MAX (9202 + 14 + 4 + 4 + 16)

szedata2
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

tap
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETHER_MAX_VLAN_FRAME_LEN (1518 + 4)

thunderx
configure() uses max_rx_pkt_len for scattering + sets internal mtu
info() returns max_rx_pktlen = NIC_HW_MAX_FRS (9200)

vhost
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

virtio
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN (9728U)

vmxnet3
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 16384;

xenvirt
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 2048


Regards,
Andriy

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Shahaf Shuler <hidden>
Date: 2018-05-23 05:21:45 

Hi Andriy,

I think this patch addressing just small issue in a bigger problem.
The way I see it all application needs to specify is the max packet size it expects to receive, nothing else(!). 
Currently we are forcing it to toggle multiple redundant fields. 

Wednesday, May 23, 2018 1:31 AM, Thomas Monjalon:
Subject: Re: [dpdk-dev] [PATCH v3] ether: use a default for max Rx frame
quoted
quoted
IMO the changes are transparent for the PMDs (please see below), but
it might affect some applications. Here is the change in API behaviour:

Before the patch:
jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len =
ETHER_MAX_LEN jumbo == 0, max_rx_pkt_len == 10, RESULT:
max_rx_pkt_len = ETHER_MAX_LEN jumbo == 0, max_rx_pkt_len ==
1200,
quoted
quoted
RESULT: max_rx_pkt_len = 1200 jumbo == 0, max_rx_pkt_len == 9K,
RESULT: max_rx_pkt_len = ETHER_MAX_LEN

jumbo == 1, max_rx_pkt_len == 0, RESULT: ERROR jumbo == 1,
max_rx_pkt_len == 10, RESULT: ERROR jumbo == 1, max_rx_pkt_len ==
1200, RESULT: max_rx_pkt_len = 1200 jumbo == 1, max_rx_pkt_len ==
9K, RESULT: ERROR or max_rx_pkt_len = 9K jumbo == 1, max_rx_pkt_len
== 90K, RESULT: ERROR


After the patch:
jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len =
ETHER_MAX_LEN jumbo == 0, max_rx_pkt_len == 10, RESULT: ERROR
(changed) jumbo == 0, max_rx_pkt_len == 1200, RESULT:
max_rx_pkt_len
quoted
quoted
= 1200 jumbo == 0, max_rx_pkt_len == 9K, RESULT: ERROR (changed)
For example in the line above - the application wants to receive 9K frames. Why it is an error? Why forcing the application to set another redundant bit?
IMO The "jumbo_frame" bit can be set by the underlying PMD directly to the device registers given the max_rx_pkt_len configuration. 

Same apply to DEV_RX_OFFLOAD_SCATTER flag. Application doesn't need to set it. the PMD will choose the put multiple mbufs in Rx descriptor given the mbuf size and the max_rx_packet_len. 
API should be informative enough for the application to expect multi-segment packets on the receive. 

Finally the MTU. It is correct it stands for "max transmit unit" but it is threaded in the same way max_rx_pkt_len is (i.e. MTU sets the max packet len the port receives). 
We need to either clarify it only address transmit or remove it completely and maybe change max_rx_pkt_len name to mtu.
quoted
quoted
jumbo == 1, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = dev_info()
jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR jumbo == 1,
max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 jumbo == 1,
max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K jumbo
==
quoted
quoted
1, max_rx_pkt_len == 90K, RESULT: ERROR

Only the apps which requested too small or too big normal frames
will be affected. In most cases it will be rather an error in the app...


Also I have looked through all the PMDs to confirm they are not
affected. Here is the summary:

af_packet
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETH_FRAME_LEN (1514)

ark
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETH_FRAME_LEN (16K - 128)

avp
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = avp->max_rx_pkt_len
rx_queue_setup() uses max_rx_pkt_len for scattering

bnx2x
configure() uses max_rx_pkt_len to set internal mtu
info() returns max_rx_pktlen = BNX2X_MAX_RX_PKT_LEN (15872)

bnxt
configure() uses max_rx_pkt_len to set internal mtu
info() returns max_rx_pktlen = BNXT_MAX_MTU + ETHER_HDR_LEN +
ETHER_CRC_LEN + VLAN_TAG_SIZE (9000 + 14 + 4 + 4)

bonding
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = internals->candidate_max_rx_pktlen or
ETHER_MAX_JUMBO_FRAME_LEN (0x3F00)

cxgbe
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = CXGBE_MAX_RX_PKTLEN (9000 + 14 + 4)
rx_queue_setup() checks max_rx_pkt_len boundaries

dpaa2
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = DPAA2_MAX_RX_PKT_LEN (10240)

e1000 (em)
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = em_get_max_pktlen() (0x2412, 0x1000,
1518, 0x3f00, depends on model)

e1000 (igb)
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 0x3fff
start() writes max_rx_pkt_len to HW for jumbo frames only
start() uses max_rx_pkt_len for scattering

ena
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = adapter->max_mtu
start() checks max_rx_pkt_len boundaries

enic
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = enic->max_mtu + 14 + 4

fm10k
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = FM10K_MAX_PKT_SIZE (15 * 1024)
start() uses max_rx_pkt_len for scattering

i40e
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = I40E_FRAME_SIZE_MAX (9728)
rx_queue_config() checks max_rx_pkt_len boundaries

ixgbe
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 15872 (9728 for vf)
start() writes max_rx_pkt_len to HW for jumbo frames only
start() uses max_rx_pkt_len for scattering

kni
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = UINT32_MAX

liquidio
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = LIO_MAX_RX_PKTLEN (64K)
start() checks max_rx_pkt_len boundaries

mlx4
configure() uses max_rx_pkt_len for scattering
info() returns max_rx_pktlen = 65536

mlx5
configure() uses max_rx_pkt_len for scattering
info() returns max_rx_pktlen = 65536

nfp
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = hw->mtu

null
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

pcap
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

qede
configure() uses max_rx_pkt_len for scattering + internal data
info() returns max_rx_pktlen = ETH_TX_MAX_NON_LSO_PKT_LEN (9700
- 4
quoted
quoted
- 4
- 12 - 8)

ring
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

sfc
configure() uses max_rx_pkt_len to set internal data
info() returns max_rx_pktlen = EFX_MAC_PDU_MAX (9202 + 14 + 4 + 4 +
16)

szedata2
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

tap
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = ETHER_MAX_VLAN_FRAME_LEN (1518 +
4)
quoted
quoted
thunderx
configure() uses max_rx_pkt_len for scattering + sets internal mtu
info() returns max_rx_pktlen = NIC_HW_MAX_FRS (9200)

vhost
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = (uint32_t)-1

virtio
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN (9728U)

vmxnet3
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 16384;

xenvirt
configure() does not use max_rx_pkt_len
info() returns max_rx_pktlen = 2048


Regards,
Andriy

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Jerin Jacob <hidden>
Date: 2018-05-23 05:23:55 

-----Original Message-----
Date: Wed, 23 May 2018 05:21:43 +0000
From: Shahaf Shuler <redacted>
To: Thomas Monjalon <redacted>, Andriy Berestovskyy
 [off-list ref]
CC: "dev@dpdk.org" <redacted>, Bruce Richardson
 [off-list ref], "ferruh.yigit@intel.com"
 [off-list ref], "arybchenko@solarflare.com"
 [off-list ref], "hemant.agrawal@nxp.com"
 [off-list ref], "jerin.jacob@cavium.com"
 [off-list ref]
Subject: RE: [dpdk-dev] [PATCH v3] ether: use a default for max Rx frame
 size in configure()

Hi Andriy,

I think this patch addressing just small issue in a bigger problem.
The way I see it all application needs to specify is the max packet size it expects to receive, nothing else(!). 
+1

Currently we are forcing it to toggle multiple redundant fields.

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Andriy Berestovskyy <hidden>
Date: 2018-05-24 09:20:20 

Hi Shahaf,

On 23 May 2018, at 07:21, Shahaf Shuler [off-list ref] wrote:
I think this patch addressing just small issue in a bigger problem.
The way I see it all application needs to specify is the max packet size it expects to receive, nothing else(!). 
[...]

IMO The "jumbo_frame" bit can be set by the underlying PMD directly to the device registers given the max_rx_pkt_len configuration. 
Sure, it can be deducted in PMD if max_rx_pkt_len is greater than the normal frame size.

The background behind this patch was to fix some examples on some platforms by allowing them to just set the jumbo bit in config and let the DPDK to deduct the optimal jumbo max_rx_pkt_len.

There was also another patch which fixed those examples, so they first query the max_rx_pkt_len and then pass it with the config:
http://dpdk.org/commit/5e470a6654

That patch has been merged, so now we can fix/change the API in any way we decide, there is no urgency anymore.

Looks like the jumbo bit in config is redundant, but there might be other opinions.

Andriy

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Ferruh Yigit <hidden>
Date: 2019-01-23 18:36:11 

On 5/24/2018 10:20 AM, Andriy Berestovskyy wrote:
Hi Shahaf,
quoted
On 23 May 2018, at 07:21, Shahaf Shuler [off-list ref] wrote:
I think this patch addressing just small issue in a bigger problem.
The way I see it all application needs to specify is the max packet size it expects to receive, nothing else(!). 
[...]
quoted
IMO The "jumbo_frame" bit can be set by the underlying PMD directly to the device registers given the max_rx_pkt_len configuration. 
Sure, it can be deducted in PMD if max_rx_pkt_len is greater than the normal frame size.

The background behind this patch was to fix some examples on some platforms by allowing them to just set the jumbo bit in config and let the DPDK to deduct the optimal jumbo max_rx_pkt_len.

There was also another patch which fixed those examples, so they first query the max_rx_pkt_len and then pass it with the config:
http://dpdk.org/commit/5e470a6654

That patch has been merged, so now we can fix/change the API in any way we decide, there is no urgency anymore.

Looks like the jumbo bit in config is redundant, but there might be other opinions.
Back to this old issue, the mentioned inconsistency is still exist in the
current code, and this or relevant ones mentioned a few times already.

What would you think about developing an unit test on 19.05 to test these on
ethdev, and ask vendors to run it and fix failures in next releases?
A more TDD approach, first right the test that fails, later fix it.
If there is a support I can start writing it but will require support.


And related issues:
max_rx_pkt_len
DEV_RX_OFFLOAD_JUMBO_FRAME
DEV_TX_OFFLOAD_MULTI_SEGS
scattered_rx
mtu


These are provided by user as config option, but some drivers updates some of
them, initial question is, are they input only or can be modified by drivers.

Like if user not requested JUMBO_FRAME but provided a large max_rx_pkt_len,
should user get an error or should PMD enable jumbo frame itself?


And another question around 'max_rx_pkt_len' / 'mtu', both are related and
close. 'max_rx_pkt_len' is frame size as far as I can understand, and since we
have capability to set 'mtu', this looks duplicate.
And I assume users are mostly will be interested in 'mtu', for given 'mtu'
driver can calculate 'max_rx_pkt_len' taking other config options into account
affecting frame size.

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Andriy Berestovskyy <hidden>
Date: 2019-01-25 21:15:18 

Sure, Ferruh.
Just let me know how can I help you.

Andriy

On 23 Jan 2019, at 19:36, Ferruh Yigit [off-list ref] wrote:
quoted
On 5/24/2018 10:20 AM, Andriy Berestovskyy wrote:
Hi Shahaf,
quoted
On 23 May 2018, at 07:21, Shahaf Shuler [off-list ref] wrote:
I think this patch addressing just small issue in a bigger problem.
The way I see it all application needs to specify is the max packet size it expects to receive, nothing else(!). 
[...]
quoted
IMO The "jumbo_frame" bit can be set by the underlying PMD directly to the device registers given the max_rx_pkt_len configuration. 
Sure, it can be deducted in PMD if max_rx_pkt_len is greater than the normal frame size.

The background behind this patch was to fix some examples on some platforms by allowing them to just set the jumbo bit in config and let the DPDK to deduct the optimal jumbo max_rx_pkt_len.

There was also another patch which fixed those examples, so they first query the max_rx_pkt_len and then pass it with the config:
http://dpdk.org/commit/5e470a6654

That patch has been merged, so now we can fix/change the API in any way we decide, there is no urgency anymore.

Looks like the jumbo bit in config is redundant, but there might be other opinions.
Back to this old issue, the mentioned inconsistency is still exist in the
current code, and this or relevant ones mentioned a few times already.

What would you think about developing an unit test on 19.05 to test these on
ethdev, and ask vendors to run it and fix failures in next releases?
A more TDD approach, first right the test that fails, later fix it.
If there is a support I can start writing it but will require support.


And related issues:
max_rx_pkt_len
DEV_RX_OFFLOAD_JUMBO_FRAME
DEV_TX_OFFLOAD_MULTI_SEGS
scattered_rx
mtu


These are provided by user as config option, but some drivers updates some of
them, initial question is, are they input only or can be modified by drivers.

Like if user not requested JUMBO_FRAME but provided a large max_rx_pkt_len,
should user get an error or should PMD enable jumbo frame itself?


And another question around 'max_rx_pkt_len' / 'mtu', both are related and
close. 'max_rx_pkt_len' is frame size as far as I can understand, and since we
have capability to set 'mtu', this looks duplicate.
And I assume users are mostly will be interested in 'mtu', for given 'mtu'
driver can calculate 'max_rx_pkt_len' taking other config options into account
affecting frame size.

Re: [PATCH v3] ether: use a default for max Rx frame size in configure()

From: Stephen Hemminger <stephen@networkplumber.org>
Date: 2023-06-08 16:51:35 

Going through the patch archives and this patch might still be
interesting, but the configuration of jumbo and receive packet
length has changed over the last 5 years.

If this is still an issue, please either file a bug in
bugzilla and/or rebase the patch on the current release.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help