![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to e.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 15.net|
Return to e.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 15.net |
1.1 root 1: .\" Copyright (c) 1983, 1986 The Regents of the University of California.
2: .\" All rights reserved.
3: .\"
4: .\" Redistribution and use in source and binary forms are permitted
5: .\" provided that the above copyright notice and this paragraph are
6: .\" duplicated in all such forms and that any documentation,
7: .\" advertising materials, and other materials related to such
8: .\" distribution and use acknowledge that the software was developed
9: .\" by the University of California, Berkeley. The name of the
10: .\" University may not be used to endorse or promote products derived
11: .\" from this software without specific prior written permission.
12: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
13: .\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
14: .\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
15: .\"
16: .\" @(#)e.t 6.4 (Berkeley) 3/7/89
17: .\"
18: .nr H2 1
19: .\".ds RH "Trailer protocols
20: .br
21: .ne 2i
22: .NH
23: \s+2Trailer protocols\s0
24: .PP
25: Core to core copies can be expensive.
26: Consequently, a great deal of effort was spent
27: in minimizing such operations. The VAX architecture
28: provides virtual memory hardware organized in
29: page units. To cut down on copy operations, data
30: is kept in page-sized units on page-aligned
31: boundaries whenever possible. This allows data
32: to be moved in memory simply by remapping the page
33: instead of copying. The mbuf and network
34: interface routines perform page table manipulations
35: where needed, hiding the complexities of the VAX
36: virtual memory hardware from higher level code.
37: .PP
38: Data enters the system in two ways: from the user,
39: or from the network (hardware interface). When data
40: is copied from the user's address space
41: into the system it is deposited in pages (if sufficient
42: data is present).
43: This encourages the user to transmit information in
44: messages which are a multiple of the system page size.
45: .PP
46: Unfortunately, performing a similar operation when taking
47: data from the network is very difficult.
48: Consider the format of an incoming packet. A packet
49: usually contains a local network header followed by
50: one or more headers used by the high level protocols.
51: Finally, the data, if any, follows these headers. Since
52: the header information may be variable length, DMA'ing the eventual
53: data for the user into a page aligned area of
54: memory is impossible without
55: \fIa priori\fP knowledge of the format (e.g., by supporting
56: only a single protocol header format).
57: .PP
58: To allow variable length header information to
59: be present and still ensure page alignment of data,
60: a special local network encapsulation may be used.
61: This encapsulation, termed a \fItrailer protocol\fP [Leffler84],
62: places the variable length header information after
63: the data. A fixed size local network
64: header is then prepended to the resultant packet.
65: The local network header contains the size of the
66: data portion (in units of 512 bytes), and a new \fItrailer protocol
67: header\fP, inserted before the variable length
68: information, contains the size of the variable length
69: header information. The following trailer
70: protocol header is used to store information
71: regarding the variable length protocol header:
72: .DS
73: ._f
74: struct {
75: short protocol; /* original protocol no. */
76: short length; /* length of trailer */
77: };
78: .DE
79: .PP
80: The processing of the trailer protocol is very
81: simple. On output, the local network header indicates that
82: a trailer encapsulation is being used.
83: The header also includes an indication
84: of the number of data pages present before the trailer
85: protocol header. The trailer protocol header is
86: initialized to contain the actual protocol identifier and the
87: variable length header size, and is appended to the data
88: along with the variable length header information.
89: .PP
90: On input, the interface routines identify the
91: trailer encapsulation
92: by the protocol type stored in the local network header,
93: then calculate the number of
94: pages of data to find the beginning of the trailer.
95: The trailing information is copied into a separate
96: mbuf and linked to the front of the resultant packet.
97: .PP
98: Clearly, trailer protocols require cooperation between
99: source and destination. In addition, they are normally
100: cost effective only when sizable packets are used. The
101: current scheme works because the local network encapsulation
102: header is a fixed size, allowing DMA operations
103: to be performed at a known offset from the first data page
104: being received. Should the local network header be
105: variable length this scheme fails.
106: .PP
107: Statistics collected indicate that as much as 200Kb/s
108: can be gained by using a trailer protocol with
109: 1Kbyte packets. The average size of the variable
110: length header was 40 bytes (the size of a
111: minimal TCP/IP packet header). If hardware
112: supports larger sized packets, even greater gains
113: may be realized.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.