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

https://bitbucket.org/freebsd/freebsd-head/ · Raku · 129 lines · 129 code · 0 blank · 0 comment · 20 complexity · e54601268063ffb975bc44b89d6deba0 MD5 · raw file

  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.