From 91533356c17ab142892835f4c32129e993903c64 Mon Sep 17 00:00:00 2001 From: wblock Date: Sat, 9 Jun 2012 01:42:22 +0000 Subject: [PATCH] MFC r236122,r236595: Wording corrections and simplifications. Approved by: gjb (mentor) git-svn-id: svn://svn.freebsd.org/base/stable/8@236774 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f --- share/man/man4/vlan.4 | 36 +++++++++++++++++------------------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/share/man/man4/vlan.4 b/share/man/man4/vlan.4 index 4ef65cbf1..4717d2ae5 100644 --- a/share/man/man4/vlan.4 +++ b/share/man/man4/vlan.4 @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd October 25, 2011 +.Dd June 4, 2012 .Dt VLAN 4 .Os .Sh NAME @@ -33,7 +33,7 @@ .Nd "IEEE 802.1Q VLAN network interface" .Sh SYNOPSIS To compile this driver into the kernel, -place the following lines in your +place the following line in your kernel configuration file: .Bd -ragged -offset indent .Cd "device vlan" @@ -79,16 +79,16 @@ to a properly configured switch port. The VLAN tag should match one of those set up in the switched network. .Pp -Initially .Nm -assumes the same minimum length for tagged and untagged frames. -This mode is selected by the +initially assumes the same minimum length for tagged and untagged frames. +This mode is selected by setting the .Xr sysctl 8 variable .Va net.link.vlan.soft_pad -set to 0 (default). -However, there are network devices that fail to adjust frame length, -should it fall below the allowed minimum due to untagging. +to 0 +.Pq default . +However, there are network devices that fail to adjust frame length +when it falls below the allowed minimum due to untagging. Such devices should be able to interoperate with .Nm after changing the value of @@ -97,7 +97,7 @@ to 1. In the latter mode, .Nm will pad short frames before tagging them -so that their length stays not less than the minimum value +so that their length is not less than the minimum value after untagging by the non-compliant devices. .Sh HARDWARE The @@ -111,7 +111,7 @@ receive and transmit long frames (up to 1522 bytes including an Ethernet header and FCS). The capabilities may be user-controlled by the respective parameters to .Xr ifconfig 8 , -.Cm vlanhwtag +.Cm vlanhwtag , and .Cm vlanmtu . However, a physical interface is not obliged to react to them: @@ -119,8 +119,8 @@ It may have either capability enabled permanently without a way to turn it off. The whole issue is very specific to a particular device and its driver. .Pp -By now, the list of physical interfaces able of full VLAN processing -in the hardware is limited to the following devices: +At present, these devices are capable of full VLAN processing +in hardware: .Xr ae 4 , .Xr age 4 , .Xr alc 4 , @@ -146,11 +146,10 @@ in the hardware is limited to the following devices: and .Xr vge 4 . .Pp -The rest of the Ethernet interfaces can run -VLANs using software emulation in the +Other Ethernet interfaces can run VLANs using software emulation in the .Nm driver. -However, some of them lack the capability +However, some lack the capability of transmitting and receiving long frames. Assigning such an interface as the parent to .Nm @@ -163,9 +162,8 @@ connectivity problems due to massive, inadequate .Xr icmp 4 filtering that breaks the Path MTU Discovery mechanism. .Pp -The following interfaces support long frames for -.Nm -natively: +These interfaces natively support long frames for +.Nm : .Xr axe 4 , .Xr bfe 4 , .Xr cas 4 , @@ -198,7 +196,7 @@ for use and calculates the appropriate frame MTU based on the capabilities of the parent interface. Some other interfaces not listed above may handle long frames, -but they do not advertise this ability of theirs. +but they do not advertise this ability. The MTU setting on .Nm can be corrected manually if used in conjunction with such a parent interface. -- 2.45.0