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