[PATCH v1 1/1] net/nbl: allow MTU change when port is started

[Stephen Hemminger]

On Tue, 20 Oct 2026 02:42:27 -0700
Dimon Zhao <dimon.zhao at nebula-matrix.com> wrote:

> Remove the dev_started check in nbl_mtu_set() to allow MTU
> configuration while the port is started.
> 
> Signed-off-by: Dimon Zhao <dimon.zhao at nebula-matrix.com>
> ---

I was suspicious of this since changing MTU often requires driver to
reset lots of receive state. And AI analysis confirmed it.

[PATCH v1 1/1] net/nbl: allow MTU change when port is started

Error

The check being removed is what kept the Rx path consistent. Rx
buffer layout and scattered_rx are decided once, at queue start, in
nbl_res_alloc_rx_bufs():

	u32 frame_size = rxq->eth_dev->data->mtu + NBL_ETH_OVERHEAD +
			 rxq->exthdr_len;
	...
	if (frame_size > rxq->buf_length)
		rxq->eth_dev->data->scattered_rx = 1;

With the check gone, an application running with 2K mbufs and
MTU 1500 can raise the MTU to 9000 on a started port. Nothing
re-evaluates scattered_rx, and the application never enabled
RTE_ETH_RX_OFFLOAD_SCATTER, but it will start receiving chained
mbufs. Other PMDs that allow runtime MTU change (ixgbe, ice) reject
the case where the new frame no longer fits a single Rx buffer and
scatter is not already active. Do the same here, e.g.:

	struct rte_eth_dev_data *dev_data = eth_dev->data;
	uint32_t frame_size = mtu + NBL_ETH_OVERHEAD;

	if (dev_data->dev_started && !dev_data->scattered_rx &&
	    frame_size > dev_data->min_rx_buf_size - RTE_PKTMBUF_HEADROOM) {
		NBL_LOG(ERR, "port %u must be stopped to set MTU %u",
			dev_data->port_id, mtu);
		return -EBUSY;
	}

The limit needs to account for the Rx extended header the same way
nbl_res_alloc_rx_bufs() does (rxq->exthdr_len), so expose that
value or a per-port max single-buffer frame size to the dev layer
rather than open-coding it.

Warning

Commit message says what the patch does, not why it is now safe.
The original comment said MTU setting is forbidden while started;
something must have changed for that to no longer hold. Say what:
does the PF/management side handling NBL_CHAN_MSG_MTU_SET now apply
the new MTU to a running VSI without a queue restart, on both PF
and VF? Which firmware/kernel driver version is required? State how
this was tested (e.g. testpmd "port config mtu" with traffic
running, both growing and shrinking the MTU).