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