why MTU change from 1500 to 9000

Question

in /var/log/message file we found something interesting

Mar  9 07:08:32 linux54 kernel: ixgbe 0000:0b:00.1 en3j87: changing MTU from 1500 to 9000

we can see the interface card - en3j87 change from 1500 MTU to 9000

is it normal ?

Mar  9 07:07:33 linux54 dbus-daemon: dbus[1153]: [system] Successfully activated service 'org.freedesktop.problems'
Mar  9 07:08:30 linux54 kernel: ixgbe 0000:0b:00.1: registered PHC device on en3j87
Mar  9 07:08:30 linux54 kernel: IPv6: ADDRCONF(NETDEV_UP): en3j87: link is not ready
Mar  9 07:08:31 linux54 kernel: ixgbe 0000:0b:00.1 en3j87: detected SFP+: 5
Mar  9 07:08:31 linux54 kernel: ixgbe 0000:0b:00.1 en3j87: NIC Link is Up 10 Gbps, Flow Control: RX/TX
Mar  9 07:08:31 linux54 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): en3j87: link becomes ready
Mar  9 07:08:32 linux54 kernel: ixgbe 0000:0b:00.1: removed PHC on en3j87
Mar  9 07:08:32 linux54 kernel: ixgbe 0000:0b:00.1 en3j87: changing MTU from 1500 to 9000
Mar  9 07:08:32 linux54 kernel: ixgbe 0000:0b:00.1: registered PHC device on en3j87
Mar  9 07:08:32 linux54 kernel: IPv6: ADDRCONF(NETDEV_UP): en3j87: link is not ready
Mar  9 07:08:32 linux54 kernel: team0: Port device en3j87 added
Mar  9 07:08:32 linux54 kernel: ixgbe 0000:0b:00.1 en3j87: detected SFP+: 5
Mar  9 07:08:33 linux54 kernel: ixgbe 0000:0b:00.1 en3j87: NIC Link is Up 10 Gbps, Flow Control: RX/TX
Mar  9 07:08:33 linux54 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): en3j87: link becomes ready

Answer 1

This means that your interface has been configured to use jumbo frames. If the connection is working, then it’s nothing to worry about, and you’ll get higher throughput as a result. (If it works, it means the network equipment the interface is connected to has also been configured for jumbo frames.)

Interfaces start with a traditional 1500-byte MTU and are reconfigured to 9000 by the network setup if necessary (in RHEL, if the interface configuration specifies MTU=9000). The log message you see is perfectly normal.

Answer 2

That message is something specific of your network module (ixgbe) and totally normal(not a problem). If you take a look at the source code of that module, file ixgbe_main.c line 6719, you will notice that the driver informs whenever there is a MTU change happening. Snippet of the code for context:

static int ixgbe_change_mtu(struct net_device *netdev, int new_mtu)
{
    struct ixgbe_adapter *adapter = netdev_priv(netdev);

    if (adapter->xdp_prog) {
        int new_frame_size = new_mtu + ETH_HLEN + ETH_FCS_LEN +
                     VLAN_HLEN;
        int i;

        for (i = 0; i < adapter->num_rx_queues; i++) {
            struct ixgbe_ring *ring = adapter->rx_ring[i];

            if (new_frame_size > ixgbe_rx_bufsz(ring)) {
                e_warn(probe, "Requested MTU size is not supported with XDP\n");
                return -EINVAL;
            }
        }
    }

    /*
     * For 82599EB we cannot allow legacy VFs to enable their receive
     * paths when MTU greater than 1500 is configured.  So display a
     * warning that legacy VFs will be disabled.
     */
    if ((adapter->flags & IXGBE_FLAG_SRIOV_ENABLED) &&
        (adapter->hw.mac.type == ixgbe_mac_82599EB) &&
        (new_mtu > ETH_DATA_LEN))
        e_warn(probe, "Setting MTU > 1500 will disable legacy VFs\n");

    e_info(probe, "changing MTU from %d to %d\n", netdev->mtu, new_mtu);

    /* must set new MTU before calling down or up */
    netdev->mtu = new_mtu;

    if (netif_running(netdev))
        ixgbe_reinit_locked(adapter);

    return 0;
}

Specific line where you are supposed to be notified that the MTU has changed:

e_info(probe, "changing MTU from %d to %d\n", netdev->mtu, new_mtu);