> 3) There's no need to check the IP packet length.  Again, in the rare
>    case where it's incorrect, it will be rejected on the destination
>    host. Furthermore, truncating the packet may actually reduce
>    efficiency (e.g. by forcing us to repad a packet to send it out an
>    Ethernet interface).

Since I added that code, I might as well speak up..

"All the world's not Ethernet".

Failure to truncate the packet causes Van Jabobsen header compression
to break in subtle and messy ways, as slcompress.c assumes that ip_len
is consistent with the mbuf chain length.  This needs to be fixed
before this code can safely be removed from ipflow.  See pr#5560
(referenced in the change comment to ip_flow.c rev 1.6).

In the absence of header compression, failure to truncate will also
cause inefficiency when forwarding packets from ethernet to something
else in at least two cases:

      - slow links (where the lost time due to transmitting a handful
of extra bytes of padding will overwhelm the saving of a few CPU
cycles).

      - ATM (with the 48-byte cell size).  (ooh, we just *doubled* the
bandwidth required for TCP tinygrams because the ethernet padding
causes them to no longer fit in a single cell).

BTW, from looking through a bunch of ethernet device drivers, it looks
like:
     a) there are a bunch of different, not necessarily consistent,
definitions of ETHER_MIN_LEN in driver source files; some of them
define it to 64, others to 60.

     b) a bunch of them (presumably ones where the hardware just takes
care of it) define ETHER_MIN_LEN but never use it..

					- Bill