[OpenAFS-devel] rx mtu fix

[Lyle Seaman]

> I think the original intent was to use the mtu of the interface only if the
> remote peer was directly attached to the same net.  I was going to make the
> code do this but there appears to be little interest so I didn't bother.

The original intent was as you say, Jim.  It was a quick hack for a product 
that was supposed to die years earlier.

The thinking was that sending jumbograms on a single LAN segment was a sure 
win, sending them through one router hop was almost certainly a win, but 
sending them through increasing numbers of routers was increasingly asking for 
trouble.

The rationale behind four rather than three or five frags in a jumbogram was 
based on measurements of contemporary CPUs, and observation of diminishing 
returns beyond four frags, and the fact that Cisco routers of the period when 
configured with "fast" queues rather than "deep" ones could only buffer four 
frags from a single LAN segment.

The original implementation of jumbograms only put one RX header on a 
jumbogram, and the RX packet-handling overhead was (still is) substantial. 
Subsequent revisions of RX reintroduced the per-packet overhead for an 
MTU-sized hunk of bytes.

The "right" solution is to streamline the implementation, or to pitch RX 
entirely.

What's the current state of ECN in the world?