Subject: Re: NIC driver interface to kernel.
To: Jochen Kunz <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 12/19/2003 22:20:03
On Sun, Dec 14, 2003 at 10:02:47PM +0100, Jochen Kunz wrote:
> On Sat, 13 Dec 2003 14:05:49 -0800
> Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:
> > >By the time the driver gets it out of if_snd, it is in wire format.
> > Except without a link-level CRC.
> The i82596 does TX and RX CRC processing in hardware.
> > If you support VLAN tagging. be similary careful about VLAN tag
> > length and MTU/MRU.
> VLAN tagging? ENOCLUE. Any hints about this topic?
This is the 802.1q vlan tagging. See vlan(4).
Basically the ethernet packet type is set to 0x8100, the next 2 bytes contains
the vlan tag, and then the real type of the packet.
Some chip handle it in hardware (they provide the received frame without the
extra 4 bytes and the VLAN tag in a separate area, and add the VLAN tag
themselves on send), otherwise it's handled in software by upper layers.
When VLAN tagging is used, the frame can be up to 1518 bytes (the
extra 4 bytes added by 802.1Q), so the ethernet driver has to support it.
Most hardware can support it. If a driver can handle 1518 bytes frames,
it advertises it by setting the ETHERCAP_VLAN_MTU flag in
sc->sc_ethercom.ec_capabilities. Upper layer will request the driver to let
come in large frames by setting ETHERCAP_VLAN_MTU in
sc->sc_ethercom.ec_capenable (that is, when a vlan interface is attached to
this interface). You can see ic/lance.c for an example on how to handle this
in a driver.
Manuel Bouyer <firstname.lastname@example.org>
NetBSD: 23 ans d'experience feront toujours la difference