MTU for networking

"That depends"... :>

First, recall this is c.a.e -- so, often, the system/device need not support a wide variety of networking "options", protocols, media, etc. One (or a couple) of *particular* NICs are supported by the product... it's not like a desktop environment where you have to tolerate *any* sort of network interface being plugged.

And, even within that constraint, a developer/product could further constrain the buffer size(s) available.

Also, it depends on how high up the protocol stack you are dealing with these buffers. I.e., the higher up, the more leeway you have to deal with "virtual" buffers instead of

*physical* ones. OTOH, some network devices can treat a list/chain of smaller buffers *as* a larger buffer (to accommodate fragmentation).

So, you have to look at the needs of *your* application/device and the capabilities of your current/future hardware and decide how flexible you want the protocol stack and drivers to be.

E.g., if you are running an ethernet, you could opt for

1500 byte buffers and accept whatever "waste" comes with that decision. OTOH, if you are just expecting to deal with (e.g.) ICMP messages, you might opt for smaller buffers knowing the larger size isn't needed. If you *know* the constraints that will be imposed (or, that you *can* impose) on the traffic, you can tweek the entire protocol stack to exploit that knowledge -- at the risk of requiring a rewrite if any of those assumptions change.

HTH

Thank you. But I'm specially asking about the relationship between IP stack and physical device driver like Ethernet. If I look at the content of the Ethernet frame there is no indication of fragmentation. But it's definitely in IP part of the frame. If there is Ethernet only, then IP stack can be hardcoded for MTU as you mentioned. But typically you can have - Ethernet, USB (Ethernet via USB class) and WiFi. In that case I would assume IP stack needs to be designed the way it "learns" MTU size during the startup - either as hardcoded value for each particular interface or even stored configurable value in NAND or NOR. Or am I wrong?

IP stacks usually have a block of state per interface ( each physical driver probably maps to an interface, even if the media is shared, which is seldom the case ) and each block will have ifEntry.ifMtu as a parameter settable by said driver.

-- Les Cargill

Thx Les. Basically you say IP stack starts fragmentation of the frame depending on that parameter?

Start here:

and here:

Homogenous MTU is better if you can do it.

-- Les Cargill

The kernel maintains a table of devices along with their parameters. The driver will provide default parameters when a device is initialised. The parameters can be modified (e.g. by ifconfig) within the bounds of what the hardware and/or medium permits. E.g. ethernet is typically[1] limited to a 1500-byte MTU, while SLIP/PPP links don't have any inherent limit.

[1] Larger values may be possible ("jumbo frames"), but all devices on a segment should use the same value. This tends to limit the use of jumbo frames to specialised networks.

The IP layer will check the device's MTU for each packet which is routed through a device, and fragment the packet if it is larger than the MTU (or reject it with an ICMP fragmentation-needed error if the don't-fragment flag is set, which is usually the case for TCP).

Applications which adjust packet sizes according to the MTU need to remember that the routing tables (and thus the device through which packets are routed) can change dynamically, as can the MTU of a given device.

If several different media/protocols are intended to be supported by the same stack, then registering an interface determines the size buffers that it will need. The mechanics of how this is done are up to the stack -- the device initialization routine can be responsible for building a buffer pool that it draws on and passes to the network stack; or, the device can *tell* the network stack what it wants/needs and the network stack can then decide *if* it can provide those resources to the device (i.e., the stack can "lie" and give the device bigger buffers than it actually needs); etc. (e.g., some devices have the buffer memory *in* the NIC itself)

As I said, some devices are smart enough to manage their own memory needs. The *silicon* talks directly to memory and can "traverse" a chain of buffers so that the host need not provide

*large* buffers (of which only part may be used in any given transaction). The driver then has to know how to interpret these "filled" (in the case of Rx) buffers AS IF they were a larger contiguous buffer. (similar responsibilities exist on the Tx side)