trailers and their subtleties

John A. Shriver (
Tue, 6 Sep 88 12:04:34 EDT

Trailers only happen when the amount of data is a multiple of the page
size of the machine (512 bytes on a VAX). This is because their
(alleged) benefits have to do with replacing mbuf copies with dinking
the memory management to copy pages on the VAX. These benefits only
accrued if all of the data was page aligned and page length.

Most packets are not 512 bytes of data, so you open the connection,
give the command (maybe do a more on telnet), and wham!, you die the
trailer death.

Sun does not reccomend trailers because they don't even offer their
(alleged) benefits on a Sun. They depended on the fact that a VAX has
two memory maps. One is the CPU memory management. The other one is
the Unibus map, which mapped pages (512 bytes) in Unibus slave address
space to pages in main memory. This gave them the precision needed to
play the page alignment games.

The Sun DVMA system does DMA through the same MMU as the CPU uses.
This is cheaper (Sun always designs hardware to a price), but not as
flexible. Moreover, the routines in the VAX that did the page based
hacking (if_rubaget, if_wubaput) aren't even there on the Sun. This
is because all of their Ethernet devices have either been memory
mapped (the 3Com and Sun/Intel Multibus boards), or DMA using kernel
virutal addresses (all of the on-CPU Ethernets). The VAX routines
eased writing Unibus network drivers. (Unfortunately, their absence
on the Sun makes writing VMEbus DMA device drivers rather nasty.)
Sun uses different strategies than page dinking to speed copying,
namely enormous mbufs with an mbuf free upcall.

When a Sun gets a trailer, it has to copy the blasted trailing header
back to an mbuf at the front of the chain. It is distinctly slower to
receive trailers on a Sun.

Trailers are best disabled. They cause too many problems, and there
are disagreements on whether the performance advantages on the VAX are
real or were measurement artifacts. The hosts RFC will cover

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:14 GMT