Just tested with tap interface and the server example. Once the mtu on the interface is changed (let's say to 5000) I can send and receive 5000 bytes long frames. Do you require any additional testing?

What happens if you set the MTU to be over 9000? At some point it clashes with 802.2 LLC 802.3 header.

$ ping 192.168.69.1 -s 65000

works OK (MTU is set to 65500 (max I can set on my OS) and I allocated appropriately sized buffers).

Interface settings:

16: tap1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 65500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000

When I send a UDP packet 65000 bytes long, it is both received by the server and returned. However, for some reason the socket buffer isn't cleared - because when I send a second packet of the same size, I get buffer exhausted error. But that is imho not related to this issue.

Haven't tested with UDP

Basically, the problem is: using jumbo frames with 802.3 or 802.1Q on the same medium is ambiguous, and it's not clear how this should be resolved. I'm leaning to rejecting all jumbo frames as invalid by default, unless explicitly enabled by a switch.

I agree. I ll add an explicit feature switch to enable/disable frames with MTU > 1500

Looking at it more:

the captured jumbo frames from wireshark have the Ethernet type set correctly (let's say Ipv4) - even for a frame 65k bytes long.

Since smoltcp doesn't even try to interpred EtherType field as length, I don't think there is anything to be done here. If the hardware doesn't support MTU > 1500, then the packet is dropped, but if it does (like with the tap device) there is no harm in processing jumbo frames. Of course, large frames can be only received if the hardware supports it, and if it does we should process them.

If we add this "jumbo frame switch" we have to validate the payload length against some MTU specified for the ethernet interface and possibly throw an error if is exceeded (or fragment the frame).

What do you think?

Ah, I guess mtu is already part of the device capabilities so disregard that. Still - is it necessary to drop large packets?

This is the relevant capability: https://github.com/m-labs/smoltcp/blob/master/src/phy/mod.rs#L198

Consider what happens if you receive a 802.1Q packet.

Consider what happens if you receive a 802.1Q packet.

It will have EtherType 0x8100, which can't be a length since it's > 1536, so the length is unknown based on the header and the end of the frame is signalled by Ethernet's existing end-of-frame signalling (loss of carrier or physical-layer-specific signalling). What am I missing?

Hm, you're right. That was a year ago so I no longer remember the context. I might have just made a mistake.

OK, glad I wasn't missing something obvious - I did a little bit of testing and it seems like smoltcp seems to work well with jumbo frames already; I will test further and either file issues if I find bugs or add an example.

Jumbo frames should Just Work by now, if someone finds they don't please open a new issue.