Ethernet MTU

[Michael Hamel]

On 27/03/2009, at 12:40 PM, Chris Johns wrote:

> THER_MAX_LEN_JUMBO is defined in cpukit/libnetworking/net/ethernet.h  
> but not used any where in the code.
>
> A check out of the FreeBSD kernel from cvs shows ETHER_MAX_LEN_JUMBO  
> also defined in net/ethernet.h but no where else (well a device  
> header which does not use it is discounted).
>
> A closer look at the e1000 driver in the FreeBSD kernel in CVS has a  
> section on Jumbo Frames. Maybe you should take a look and see where  
> it leads.


I have got back to looking at this and have made some progress; the  
e1000 driver was indeed helpful, thanks.

What I have found is that changing the MTU isn't all that  
straightforward; once the interface is up, changing the interface MTU  
(if_mtu) has no effect on the route MTU's (rmx_mtu) which are kept in  
the route metrics. The route metrics get cloned when new devices  
appear, so if the first one has an MTU of 1500 they all come out at  
1500 regardless of changes to the interface MTU. And the route MTU  
gets used if nonzero, in preference to the interface MTU.

Whether this is intentional or some sort of bug I'm not sure; it may  
be a policy issue.

So, if I change the interface MTU to 9000 before any packets get sent  
or routes come up, I get route MTU's of 9000 as well. I have the  
driver receiving packets of this size successfully into multiple  
mbufs, so all is well on that side. My remaining problem is that the  
BSD stack won't hand my driver data across multiple mbufs. The most it  
will give me is a 56-byte header in one mbuf and a 2048-byte data  
mbuf, so the outgoing packet size tops out at 2102 bytes. I'm calling  
write() with buffers of up to 32K, and they always get split up in  
this manner.

So I'm currently researching this; any ideas of where to look would be  
gratefully received.

My test environment is using TCP, the socket buffers are at the  
default 16K each, and I'm not seeing any errors. I have my own logging  
in my driver thats keeping track of what the stack hands me, so I know  
the problem is at the RTEMS end...



---
"Its only a model."

Michael Hamel
ADInstruments Ltd, Dunedin, NZ