I would *really*, *really* like to see a way in *Nemo* for hardware
drivers to indicate that a given driver is not capable of handling full
size VLAN frames.
I.e. it should be possible to write a native Nemo driver that doesn't
support full VLAN frames. (Or convert a GLDv2 driver to a Nemo
driver...)
This fasttrack addresses legacy drivers, but still requires them to be
updated to get access to VLANs, without addressing the problem as it
stands for native Nemo drivers.
Presumably clearview will need the ability to manage this for native
Nemo drivers as well (since it will itself emulate a Nemo driver). Can
the project team elaborate on this a bit more?
-- Garrett
On Fri, 2007-08-24 at 00:30 -0400, Sebastien Roy wrote:
> 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
