From: Mingming Cao <mmc@linux.ibm.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
pabeni@redhat.com, andrew+netdev@lunn.ch, haren@linux.ibm.com,
ricklind@linux.ibm.com, nnac123@linux.ibm.com,
davemarq@linux.ibm.com, vaishnavi@linux.ibm.com,
bjking1@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
mmc@linux.ibm.com
Subject: [PATCH net-next v1 2/6] ibmvnic: honour the requested mtu instead of reverting to a fallback
Date: Wed, 5 Aug 2026 15:43:57 -0700 [thread overview]
Message-ID: <20260805224401.58791-3-mmc@linux.ibm.com> (raw)
In-Reply-To: <20260805224401.58791-1-mmc@linux.ibm.com>
No mtu other than 1500 or 9000 can be set on an ibmvnic interface. Any
other value is accepted by ip(8) but silently reverts:
# ip link set mtu 1414 env8
ibmvnic 30000008: req=1428, rsp=1514 in mtu queue, retrying.
mtu of 1428 is not supported. Reverting.
ibmvnic 30000008: req=1514, rsp=1514 in mtu queue, retrying.
mtu of 1514 is not supported. Reverting.
# ip link show env8 | grep -o 'mtu [0-9]*'
mtu 1500
The backing device runs at one of a small set of fixed sizes, so the
vnicserver answers every REQ_MTU between the advertised minimum and
maximum with PARTIALSUCCESS and the size it settled on: 1514 for
anything up to 1514, 9014 for anything above that. It is reporting what
the backing device carries. Requests outside the advertised range never
get here, since dev_set_mtu() rejects them against netdev->min_mtu and
netdev->max_mtu.
The driver read that as a rejection. It reverted req_mtu to
fallback.mtu and re-ran the exchange, which is why the log above shows
the revert twice: the fallback is in range as well, so it partially
succeeds too and the mtu settles on whatever the fallback was.
Treat a PARTIALSUCCESS that covers the request as the confirmation it
is, and keep the requested value.
The response can also come back below the request. The advertised
maximum is the protocol ceiling rather than a promise about the current
backing configuration, so a device that is not set up for the larger
size answers with the smaller one it does carry. That does not cover
the request and must not be published, so it keeps the existing retry,
which now also stores the response value rather than reverting to a
fallback. It therefore converges on a size the device can carry instead
of re-requesting the same number. Other capabilities are unchanged.
Later patches in this series make the resets that follow a real mtu
change safe (and, on net-next, skip them when the buffers already fit).
Fixes: e79138034068 ("ibmvnic: Revert to previous mtu when unsupported value requested")
Reviewed-by: Dave Marquardt <davemarq@linux.ibm.com>
Tested-by: Vaishnavi Bhat <vaishnavi@linux.ibm.com>
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 34 ++++++++++++++++++------------
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 86e643ee6b3b..f5f9c0d5b4e6 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -5502,12 +5502,17 @@ static void handle_request_cap_rsp(union ibmvnic_crq *crq,
{
struct device *dev = &adapter->vdev->dev;
u64 *req_value;
+ u64 rsp_value;
char *name;
+ u16 cap;
atomic_dec(&adapter->running_cap_crqs);
netdev_dbg(adapter->netdev, "Outstanding request-caps: %d\n",
atomic_read(&adapter->running_cap_crqs));
- switch (be16_to_cpu(crq->request_capability_rsp.capability)) {
+
+ cap = be16_to_cpu(crq->request_capability_rsp.capability);
+
+ switch (cap) {
case REQ_TX_QUEUES:
req_value = &adapter->req_tx_queues;
name = "tx";
@@ -5546,21 +5551,22 @@ static void handle_request_cap_rsp(union ibmvnic_crq *crq,
case SUCCESS:
break;
case PARTIALSUCCESS:
- dev_info(dev, "req=%lld, rsp=%ld in %s queue, retrying.\n",
- *req_value,
- (long)be64_to_cpu(crq->request_capability_rsp.number),
- name);
-
- if (be16_to_cpu(crq->request_capability_rsp.capability) ==
- REQ_MTU) {
- pr_err("mtu of %llu is not supported. Reverting.\n",
- *req_value);
- *req_value = adapter->fallback.mtu;
- } else {
- *req_value =
- be64_to_cpu(crq->request_capability_rsp.number);
+ rsp_value = be64_to_cpu(crq->request_capability_rsp.number);
+
+ /* Covering PARTIALSUCCESS: keep the request. Otherwise
+ * retry with rsp_value.
+ */
+ if (cap == REQ_MTU && rsp_value >= *req_value) {
+ netdev_dbg(adapter->netdev,
+ "backing mtu %llu covers requested %llu\n",
+ rsp_value, *req_value);
+ break;
}
+ dev_info(dev, "req=%lld, rsp=%lld in %s queue, retrying.\n",
+ *req_value, rsp_value, name);
+ *req_value = rsp_value;
+
send_request_cap(adapter, 1);
return;
default:
--
2.50.1 (Apple Git-155)
next prev parent reply other threads:[~2026-08-05 22:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 22:43 [PATCH net-next v1 0/6] ibmvnic: honour flexible in-range MTU values Mingming Cao
2026-08-05 22:43 ` [PATCH net-next v1 1/6] ibmvnic: cap rx pool entries against the real buffer size Mingming Cao
2026-08-05 22:43 ` Mingming Cao [this message]
2026-08-05 22:43 ` [PATCH net-next v1 3/6] ibmvnic: do not unmap long term buffers across a crq reconnect Mingming Cao
2026-08-05 22:43 ` [PATCH net-next v1 4/6] ibmvnic: allocate new buffer pools before releasing the old ones Mingming Cao
2026-08-05 22:44 ` [PATCH net-next v1 5/6] ibmvnic: allocate a new long term buffer before freeing the old one Mingming Cao
2026-08-05 22:44 ` [PATCH net-next v1 6/6] ibmvnic: change the mtu without a reset where the buffers allow it Mingming Cao
2026-08-06 2:38 ` [PATCH net-next v1 0/6] ibmvnic: honour flexible in-range MTU values Jakub Kicinski
2026-08-06 5:28 ` mingming cao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260805224401.58791-3-mmc@linux.ibm.com \
--to=mmc@linux.ibm.com \
--cc=andrew+netdev@lunn.ch \
--cc=bjking1@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=davemarq@linux.ibm.com \
--cc=edumazet@google.com \
--cc=haren@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=nnac123@linux.ibm.com \
--cc=pabeni@redhat.com \
--cc=ricklind@linux.ibm.com \
--cc=vaishnavi@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.