share/doc/smm/18.net/e.t

   1 .\" Copyright (c) 1983, 1986, 1993
   2 .\"     The Regents of the University of California.  All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. Neither the name of the University nor the names of its contributors
  13 .\"    may be used to endorse or promote products derived from this software
  14 .\"    without specific prior written permission.
  15 .\"
  16 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  17 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  19 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  20 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  21 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  22 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  23 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  24 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  26 .\" SUCH DAMAGE.
  27 .\"
  28 .\"     @(#)e.t 8.1 (Berkeley) 6/8/93
  29 .\"
  30 .nr H2 1
  31 .\".ds RH "Trailer protocols
  32 .br
  33 .ne 2i
  34 .NH
  35 \s+2Trailer protocols\s0
  36 .PP
  37 Core to core copies can be expensive.
  38 Consequently, a great deal of effort was spent
  39 in minimizing such operations.  The VAX architecture
  40 provides virtual memory hardware organized in
  41 page units.  To cut down on copy operations, data
  42 is kept in page-sized units on page-aligned
  43 boundaries whenever possible.  This allows data
  44 to be moved in memory simply by remapping the page
  45 instead of copying.  The mbuf and network
  46 interface routines perform page table manipulations
  47 where needed, hiding the complexities of the VAX
  48 virtual memory hardware from higher level code.
  49 .PP
  50 Data enters the system in two ways: from the user,
  51 or from the network (hardware interface).  When data
  52 is copied from the user's address space
  53 into the system it is deposited in pages (if sufficient
  54 data is present).
  55 This encourages the user to transmit information in
  56 messages which are a multiple of the system page size.
  57 .PP
  58 Unfortunately, performing a similar operation when taking
  59 data from the network is very difficult.
  60 Consider the format of an incoming packet.  A packet
  61 usually contains a local network header followed by
  62 one or more headers used by the high level protocols.
  63 Finally, the data, if any, follows these headers.  Since
  64 the header information may be variable length, DMA'ing the eventual
  65 data for the user into a page aligned area of
  66 memory is impossible without
  67 \fIa priori\fP knowledge of the format (e.g., by supporting
  68 only a single protocol header format).
  69 .PP
  70 To allow variable length header information to
  71 be present and still ensure page alignment of data,
  72 a special local network encapsulation may be used.
  73 This encapsulation, termed a \fItrailer protocol\fP [Leffler84],
  74 places the variable length header information after
  75 the data.  A fixed size local network
  76 header is then prepended to the resultant packet.
  77 The local network header contains the size of the
  78 data portion (in units of 512 bytes), and a new \fItrailer protocol
  79 header\fP, inserted before the variable length
  80 information, contains the size of the variable length
  81 header information.  The following trailer
  82 protocol header is used to store information
  83 regarding the variable length protocol header:
  84 .DS
  85 ._f
  86 struct {
  87         short   protocol;       /* original protocol no. */
  88         short   length; /* length of trailer */
  89 };
  90 .DE
  91 .PP
  92 The processing of the trailer protocol is very
  93 simple.  On output, the local network header indicates that
  94 a trailer encapsulation is being used.
  95 The header also includes an indication
  96 of the number of data pages present before the trailer
  97 protocol header.  The trailer protocol header is
  98 initialized to contain the actual protocol identifier and the
  99 variable length header size, and is appended to the data
 100 along with the variable length header information.
 101 .PP
 102 On input, the interface routines identify the
 103 trailer encapsulation
 104 by the protocol type stored in the local network header,
 105 then calculate the number of
 106 pages of data to find the beginning of the trailer.
 107 The trailing information is copied into a separate
 108 mbuf and linked to the front of the resultant packet.
 109 .PP
 110 Clearly, trailer protocols require cooperation between
 111 source and destination.  In addition, they are normally
 112 cost effective only when sizable packets are used.  The
 113 current scheme works because the local network encapsulation
 114 header is a fixed size, allowing DMA operations
 115 to be performed at a known offset from the first data page
 116 being received.  Should the local network header be
 117 variable length this scheme fails.
 118 .PP
 119 Statistics collected indicate that as much as 200Kb/s
 120 can be gained by using a trailer protocol with
 121 1Kbyte packets.  The average size of the variable
 122 length header was 40 bytes (the size of a
 123 minimal TCP/IP packet header).  If hardware
 124 supports larger sized packets, even greater gains
 125 may be realized.