2007/527 Addendum for Clearview Vanity Naming and Nemo Unification
Sebastien Roy
Sebastien.Roy at Sun.COM
Wed Sep 12 09:09:12 PDT 2007
I'm sponsoring this fast-track request for Cathy Zhou and the Clearview
team. The timer is set for 09/19/2007.
Note that this case addresses some technical issues raised during the
review of 2007/484, which was itself closed withdrawn.
Addendum for Clearview Vanity Naming and Nemo Unification
Release binding: patch
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 one potential problem when deploying VLAN network over
certain legacy devices: such legacy devices simply assume that the
maximum payload size they can handle is 1500 bytes, and if they
receive (or are requested to send) any payload whose size is greater
than it, the driver will silently drop the packets. As a result, the
maximum packet size such devices can handle is 1514 bytes (1500
bytes of payload and 14 bytes of Ethernet header), and it does not
leave any room for extra 4 bytes of VLAN tags. 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 to query
each Ethernet network device whether such problem exists, i.e.,
whether the device can handle extra 4 bytes of payload for VLAN tags
besides the maximum SDU size that is reported in DL_INFO_ACK.
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
behalves, 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.
In summary, a mechanism is needed to query specific network device
whether it:
- leaves extra room in the payload section besides the maximum SDU
size reported in DL_INFO_ACK. The extra room (margin) can be used
to provide additional headers.
- supports the VLAN PPA access.
Proposal overview
=================
* The issues with the old proposal - DLIOCVLANINFO ioctl
A DLIOCVLANINFO ioctl was originally proposed by PSARC 2006/499 to
report device's "VLAN capability". With this ioctl, we would be able
to know whether or not a DLPI provider is capable of handling extra
4 bytes for VLAN tags (see more in PSARC 2006/499).
Although this proposal is sufficient for general VLAN support, it
can not satisify similiar needs from other features that involves
packets of uncommon size (e.g., nested VLAN, RBridges). It is
because the DLIOCVLANINFO does not report the exact "margin" size
one device can tolerate.
* DLIOCMARGININFO ioctl
To address issues of the old proposal, we would like to introduce a
new DLIOCMARGININFO ioctl and obsolete the old DLIOCVLANINFO
ioctl. Note that the new ioctl is no longer specific to Ethernet
DLPI providers.
Specifically, the DLIOCMARGININFO ioctl takes a 32 bit integer
argument which is used for each network DLPI provider to return the
margin size it supports. For example, if an Ethernet DLPI provider
cannot handle packets whose payload section are not greater than
1522 bytes, and the maximum SDU size it reports through DL_INFO_ACK
is 1500. Then the margin size of this DLPI provider is 22
(1522-1500), and the maximum packets size it can handle is 1536
(1522+14, where 14 is the Ethernet header).
Commitment level: Committed
* GLDv3 changes
** m_margin field in mac_register_t
A new m_margin field will be added to the mac_register_t
structure. GLDv3 MACs that can handle non-zero margin size will
need to fill in the m_margin field before it registers to the
GLDv3 framework.
** mi_margin field in mac_info_t
A new mi_margin field will be added to the mac_info_t structure.
The GLDv3 framework will fill in this field for each MAC once it
registers to the GLDv3 framework. Therefore, other modules will
be able to know specific MAC's margin size information by
accessing the value of mi_margin.
For example, the dls module will be able to determine whether
VLANs can be created over a specific MAC without specifying "-f",
by comparing mi_margin with 4 (extra size for VLAN tags).
The mi_margin value will also be reported in the acknowledgment
of the DLIOCMARGININFO ioctl.
** MAC_CAPAB_NO_NATIVEVLAN
A MAC_CAPAB_NO_NATIVEVLAN MAC capability will be added to the
GLDv3 framework to indicate that a specific MAC cannot support
VLAN PPA access by itself.
Commitment level: Consolidation Private
* GLDv2 changes
** gldm_margin field in gld_mac_info_t
A new gldm_margin field will be added to the gld_mac_info_t
structure (a previous uint32_t reserved field will be
used). GLDv2 MACs that can handle non-zero margin size will need
to fill in the gldm_margin field before it registers to the GLDv2
framework.
A GLDv2 Ethernet device which registers its gldm_send_tagged()
callback will be considered as capable of VLAN PPA access, and
its margin will be corrected as 4 if the registered gldm_margin
value is 0.
The GLDv2 MAC's margin size will then be reported in the
acknowledgment of the DLIOCMARGININFO ioctl.
Commitment level: Committed
Deliverables
============
The deliverables of this case will include the header files that
define the above interfaces (specifically, <sys/dlpi.h>, <sys/gld.h>
and <sys/mac.h>), and the changes needed in the GLDv2 and GLDv3
framework.
The logic that makes use of these interfaces for general VLAN support
will be integrated separately as part of PSARC 2006/499.
We will also coordinate with other teams to report the correct margin
value for each driver, to avoid potential problems caused by
integration of PSARC 2006/499. Specifically, each DLPI driver
(firstly ce) will be changed to acknowledge the DLIOCMARGININFO ioctl
with the correct margin value; each GLDv2 and GLDv3 driver will need
to be updated to register its margin value. Before going through
every GLDv2/GLDv3 drivers, we will first change each GLDv3 Ethernet
driver in ON to register its m_margin as 4, to allow backward
compatibility of VLAN support. For the same reason, we will also
change GLDv2 drivers that have their gldm_send_tagged() callbacks
implemented to register their margin value as 4.
Documentation Impact
====================
* dlpi(7p) - Committed
$ diff -u /tmp/dlpi.man /tmp/dlpi.man.new
--- /tmp/dlpi.man Mon Sep 3 22:05:58 2007
+++ /tmp/dlpi.man.new Mon Sep 3 22:24:29 2007
@@ -340,7 +340,23 @@
erate responses with dl_mac_type set to the native DLPI
type.
+ Margin Size
+ The margin size represents the extra payload size a DLPI
+ provider can handle, aside from the maximum SDU size
+ reported in DL_INFO_ACK. For example, assuming an Ethernet
+ DLPI provider reports its maximum SDU size as 1500, but
+ it leaves room for extra payload, so that the maximum payload
+ it allows to send or pass up is 1522, then the margin size
+ of this specific DLPI provider is 22. Margin can be used
+ to carry additional headers.
+
+ DLIOCMARGININFO ioctl is used to query specific DLPI provider
+ of its margin size. In particular, this ioctl takes a 32
+ bit integer argument which is used for each DLPI provider
+ to return its margin size.
+
DL_ETHER-SPECIFIC DLPI SEMANTICS
VLAN Support
VLAN PPA Access
* gld_mac_info(9S) - Committed
$ diff -u /tmp/gld_mac_info.man /tmp/gld_mac_info.man.new
--- /tmp/gld_mac_info.man Mon Sep 3 22:27:41 2007
+++ /tmp/gld_mac_info.man.new Mon Sep 3 22:44:31 2007
@@ -50,6 +50,8 @@
/* accepted by driver */
uint32_t gldm_maxpkt; /* Maximum packet
size */
/* accepted by driver */
+ uint32_t gldm_margin; /* Margin size */
+ /* accepted by driver */
uint32_t gldm_addrlen; /* Physical address */
/* length */
int32_t gldm_saplen; /* SAP length for */
@@ -177,19 +179,22 @@
gldm_minpkt Minimum Service Data Unit size -
- the minimum packet size, not
- including the MAC header, that the
- device will transmit. This can be
+ the minimum size of SDU (service data
+ unit) that the device will transmit.
+ SDU represents the payload data sent
+ by the upper layer, which does not
+ includes the MAC header. gldm_minpkt
+ can be zero if the device-specific driver
can handle any required padding.
gldm_maxpkt Maximum Service Data Unit size -
- the maximum size of packet, not
- including the MAC header, that can
- be transmitted by the device. For
+ the maximum size of SDU that can be
+ transmitted by the device. For
Ethernet, this number is 1500.
+ gldm_margin The margin size that can be handled
+ by the device. See dlpi(7P).
SunOS 5.11 Last change: 7 June 2004 3
References
==========
[1] Vanity Naming and Nemo Unification High-Level Design Specification
http://sac.sfbay/PSARC/2006/499/commitment.materials/uv-design.pdf
More information about the opensolaris-arc
mailing list