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 6/6] ibmvnic: change the mtu without a reset where the buffers allow it
Date: Wed, 5 Aug 2026 15:44:01 -0700 [thread overview]
Message-ID: <20260805224401.58791-7-mmc@linux.ibm.com> (raw)
In-Reply-To: <20260805224401.58791-1-mmc@linux.ibm.com>
With the earlier patches in this series, in-range mtus are honoured
instead of snapped to 1500 or 9000. Every such change still cycles the
adapter through wait_for_reset(), which tears down the CRQ, logs in
again and rebuilds every queue. The link goes down for around two
seconds each time, even when the change needs nothing from the VIOS.
Most of them do not. The backing device runs at one of a small set of
fixed sizes and the vnicserver reports that size when it answers
REQ_MTU, so any mtu within it is already carried end to end. Record it
as adapter->backing_mtu (set when the covering PARTIALSUCCESS path from
the honour-mtu patch accepts a request) and skip the reset when the new
mtu is within it and the tx buffers are large enough as they are, which
covers every decrease and the increases that stay inside the current
buffer size.
Both conditions are needed. Buffer sizes are rounded up to a cache
line, so buffers alone would also admit an mtu somewhat past what the
backing device carries: with a 1514 backing mtu, everything up to 1532
aligns to the same 1536-byte buffer. Those frames would leave the
partition and be dropped by a backing device still configured for the
smaller size.
An increase past backing_mtu still resets, since it has to be put to
the vnicserver rather than assumed. Whatever comes back becomes the new
backing_mtu, so if the device does move up, later changes within the
larger size settle without a reset, and if it does not, the mtu is
renegotiated down to what the device carries and the fast path keeps
measuring against the truth.
Buffers are left at their existing size on a decrease rather than
shrunk. reuse_tx_pools() compares prev_mtu against req_mtu, so the next
reset for any reason reallocates them.
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 | 35 +++++++++++++++++++++++++++---
drivers/net/ethernet/ibm/ibmvnic.h | 1 +
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 88d0c231a74f..1d18a0e13cad 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -3705,8 +3705,34 @@ out:
static int ibmvnic_change_mtu(struct net_device *netdev, int new_mtu)
{
struct ibmvnic_adapter *adapter = netdev_priv(netdev);
+ u64 new_mtu_with_hdr = new_mtu + ETH_HLEN;
+ u64 old_buff_size, new_buff_size;
+
+ if (adapter->req_mtu == new_mtu_with_hdr)
+ return 0;
+
+ old_buff_size = ALIGN(adapter->prev_mtu + VLAN_HLEN, L1_CACHE_BYTES);
+ new_buff_size = ALIGN(new_mtu_with_hdr + VLAN_HLEN, L1_CACHE_BYTES);
+
+ /* Skip the reset when backing_mtu and the current buffers already
+ * cover the new mtu. Keep desired.mtu in sync with req_mtu.
+ */
+ if (new_mtu_with_hdr <= adapter->backing_mtu &&
+ new_buff_size <= old_buff_size) {
+ netdev_dbg(netdev, "mtu %u->%d without reset\n",
+ netdev->mtu, new_mtu);
+
+ WRITE_ONCE(netdev->mtu, new_mtu);
+ adapter->req_mtu = new_mtu_with_hdr;
+ adapter->desired.mtu = new_mtu_with_hdr;
+
+ return 0;
+ }
+
+ netdev_dbg(netdev, "mtu %u->%d needs larger buffers, resetting\n",
+ netdev->mtu, new_mtu);
- adapter->desired.mtu = new_mtu + ETH_HLEN;
+ adapter->desired.mtu = new_mtu_with_hdr;
return wait_for_reset(adapter);
}
@@ -5558,14 +5584,17 @@ static void handle_request_cap_rsp(union ibmvnic_crq *crq,
switch (crq->request_capability_rsp.rc.code) {
case SUCCESS:
+ if (cap == REQ_MTU)
+ adapter->backing_mtu = *req_value;
break;
case PARTIALSUCCESS:
rsp_value = be64_to_cpu(crq->request_capability_rsp.number);
- /* Covering PARTIALSUCCESS: keep the request. Otherwise
- * retry with rsp_value.
+ /* Covering PARTIALSUCCESS: keep the request and record
+ * backing_mtu. Otherwise retry with rsp_value.
*/
if (cap == REQ_MTU && rsp_value >= *req_value) {
+ adapter->backing_mtu = rsp_value;
netdev_dbg(adapter->netdev,
"backing mtu %llu covers requested %llu\n",
rsp_value, *req_value);
diff --git a/drivers/net/ethernet/ibm/ibmvnic.h b/drivers/net/ethernet/ibm/ibmvnic.h
index 4cfedae5d89d..80e1b2f6ede5 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@ -1020,6 +1020,7 @@ struct ibmvnic_adapter {
u64 max_mtu;
u64 req_mtu;
u64 prev_mtu;
+ u64 backing_mtu; /* mtu the backing device currently carries */
u64 max_multicast_filters;
u64 vlan_header_insertion;
u64 rx_vlan_header_insertion;
--
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 ` [PATCH net-next v1 2/6] ibmvnic: honour the requested mtu instead of reverting to a fallback Mingming Cao
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 ` Mingming Cao [this message]
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-7-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox