On Tue, 20 Oct 2026 02:42:27 -0700 Dimon Zhao <[email protected]> wrote:
> Remove the dev_started check in nbl_mtu_set() to allow MTU > configuration while the port is started. > > Signed-off-by: Dimon Zhao <[email protected]> > --- 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).
