Most of the GIGe interfaces do provide VLAN insertion/removal. You
pass/receive it as part of the DMA descriptor.
> If it requires driver changes, then the ethernet driver folks will need
> to be involved.
I think the design MUST consider not just a poor man's VLAN way of
doing things. You and the other VLAN folks (Gleb and co) will have to iron
that out. Basically, all i am saying is that if there is going to be a
linux solution at some point, the requirement for these devices is a MUST.
Please involve me in discussions you guys end up having.
> There is also a difference between supporting hardware VLAN solutions
> and being 100% compliant: If I can send/receive packets that are
> 100% compliant from an RTL 8139 NIC, then as far as the world (ie Switch) knows,
> I am 100% compliant.
> If the specific VLAN hardware features are not supported in some exotic
> NIC, then that should just mean slightly less performance, or worst cast,
> not supporting that particular NIC.
The included design must be flexible enough to allow for this. As much as
i hate it, some vendors will continue releasing binaries only for their
> My vlan code supports setting of Priority bits already (thats' the .1P, right?)
right. There's a lot of work to be done in that area.
> What is the .1D stuff about?
spanning tree. Seems the bridging code already does this.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/