I'm sponsoring this fast-track request for Cathy Zhou. The timer is set
for 08/31/2007.
Release binding: patch
Commitment level: Committed
Problem area
============
Among various goals of the Clearview Vanity naming and Nemo
unification project (PSARC 2006/499), one important goal is to
provide VLAN support for all Ethernet network devices.
There is potentially one problem when deploying a VLAN network over
certain legacy devices: some legacy devices simply assume that the
maximum frame size they can handle is 1514 bytes, and if they
receive (or are requested to send) any packet whose size is greater
than that, the driver will silently drop the packets. In order to
make the VLAN deployment successful, in such circumstance, we
require administrators to create VLANs explicitly using the "-f"
option, and they would also have to carefully configure the MTU of
each node on the VLAN to be lower.
To enforce that requirement, a mechanism will be needed for the
GLDv3 framework to query into each network device to know whether
such problem exists.
Further, although some legacy drivers do not have the MTU issue
mentioned above, they still can not support VLAN PPA access
themselves. Specifically, such drivers do not recognize the
semantics related to the VLAN PPA attachment (A DL_ATTACH_REQ whose
PPA number is calculated by multiplying the VLAN ID by 1000 and
adding the hardware PPA). For those legacy drivers, a shim layer
(softmac) will have to process such attachment request on their
behalf, and encode/demultiplex VLAN packets for them.
On the other hand, for legacy drivers who support VLAN PPA access
themselves, all control and data messages (including the VLAN PPA
DL_ATTACH_REQ message) will be directly exchanged between the upper
layer DLPI clients (such as IP) and the legacy drivers. This is
especially important for performance reasons. As a result, a
mechanism will be also needed to tell whether VLAN PPA access is
supported for specific network devices.
Proposal overview
=================
* DLIOCVLANINFO ioctl
This ioctl was defined by PSARC 2006/499 as Consolidation Private,
and is being raised to Committed by this case. The technical details
are included below and remain unchanged from what was defined in
2006/499:
To address the problem mentioned above, a new DLIOCVLANINFO ioctl
will be introduced for Ethernet network devices. The ioctl takes a
32 bit integer argument which is used for each Ethernet network
device to return one of the three VLAN capability values:
VLAN_INCAPABLE, VLAN_SIZE_CAPABLE and VLAN_FULL_CAPABLE:
- VLAN_INCAPABLE
The device cannot handle packets of bigger size, i.e., cannot
receive or send packets 4 bytes longer than the driver's advertised
maximum SDU.
- VLAN_SIZE_CAPABLE
The device can handle packets of bigger size but do not have VLAN
PPA access support.
- VLAN_FULL_CAPABLE
The device is VLAN_SIZE_CAPABLE and can also handle the VLAN PPA
DL_ATTACH_REQ.
Devices that fail to acknowledge the DLIOCVLANINFO ioctl will be
considered as VLAN_INCAPABLE.
* GLDv2 VLAN capabilities
This case adds support for DLIOCVLANINFO in the GLDv2 framework. A
GLDv2 Ethernet device which registers its gldm_send_tagged() callback
will be considered as VLAN_FULL_CAPABLE. If a driver does not
implement its gldm_send_tagger() callback but the device can handle
packets of bigger size, the device should set the GLD_CAP_VLAN_SIZE
bit of the gldm_capabilities field in gld_mac_info when it calls
gld_register(). This will result in the VLAN_SIZE_CAPABLE
acknowledgment of the DLIOCVLANINFO ioctl.
Deliverables
============
The deliverables of this case will include the header files that
define the above interfaces (specifically, <sys/dlpi.h> and
<sys.gld.h>), and the DLIOCVLANINFO support in the GLDv2 framework.
The logic that makes use of this ioctl will be integrated separately,
as part of PSARC 2006/499.
We will also coordinate with other teams to make changes to legacy
drivers (firstly, ce) to handle this ioctl, to avoid the potential
problem caused by integration of PSARC 2006/499.
Documentation Impact
====================
dlpi(7p) - Committed
$ diff -u dlpi.man.orig dlpi.man.new
--- dlpi.man.orig Tue Aug 14 04:06:33 2007
+++ dlpi.man.new Tue Aug 14 05:01:41 2007
@@ -439,6 +439,34 @@
VLAN tags or encode the VLAN tags using the priority value
specified in the VLAN headers and send the packets.
+ VLAN capability
+
+ Although some DLPI providers do not support VLAN PPA Access
+ semantics, they are able to handle packets of bigger size,
+ and potentially allow VLAN traffic which has extra 4 bits
+ of VLAN tags. DLIOCVLANINFO ioctl is used to indicate such
+ capability. In particular, this ioctl takes a 32 bit integer
+ argument which is used for each Ethernet network device to
+ return one of the three VLAN capability values:
+
+ * VLAN_INCAPABLE
+
+ The DLPI provider cannot handle packets of bigger size, i.e.,
+ cannot receive or send packets 4 bytes longer than the driver's
+ advertised maximum SDU.
+
+ * VLAN_SIZE_CAPABLE
+
+ The device can handle packets of bigger size but do not support
+ VLAN PPA access.
+
+ * VLAN_FULL_CAPABLE
+
+ The device is VLAN_SIZE_CAPABLE and can also support the VLAN PPA
+ access.
+
+ Devices that fail to acknowledge the DLIOCVLANINFO ioctl are
+ considered as VLAN_INCAPABLE.
+
FILES
Files in or under /dev.
gld_mac_info(9S) - Committed
$ diff -u /tmp/gld_mac_info /tmp/gld_mac_info.new
--- /tmp/gld_mac_info Wed Aug 22 04:03:55 2007
+++ /tmp/gld_mac_info.new Wed Aug 22 04:13:57 2007
@@ -304,12 +304,19 @@
- gldm_capabilities Bit-field of device capabilities. If
- the device is capable of reporting
- media link state, the
- GLD_CAP_LINKSTATE bit should be set.
+ gldm_capabilities Bit-field of device capabilities:
+ GLD_CAP_LINKSTATE - if a device is
+ capable of reporting media link state,
+ the GLD_CAP_LINKSTATE bit should be
+ set.
+ GLD_CAP_VLAN_SIZE - if a Ethernet
+ device is capable of transmitting and
+ receiving packets of bigger size which
+ allows VLAN traffic that has extra 4
+ bits of VLAN tags, the GLD_CAP_VLAN_SIZE
+ bit should be set; see dlpi(7p).
SEE ALSO
gld(7D), dlpi(7P), attach(9E), gld(9E), ddi_add_intr(9F),
References
==========
[1] Vanity Naming and Nemo Unification High-Level Design Specification
http://sac.sfbay/PSARC/2006/499/commitment.materials/uv-design.pdf
