Hi Garrett, Garrett D'Amore wrote: > One of the problems I've found recently is that some certain legacy > devices that should be able to support GLDv3 might not be able to > support full size VLAN frames. > > This creates a problem, as Nemo/GLDv3 does not provide a way for NICs to > advertise whether or not they can support such VLAN frames. It would be > nice to have a way to indicate to the framework that either VLAN was not > supported, or that there was an ethernet MTU limitation. (In fact, *BSD > provides just such a facility.) > > It would be nice to convert older NICs to GLDv3 even in the absence of > VLAN support, as they could gain from support for 803.ad link > aggregation as well as other newer Nemo features. (Stack instances > anyone?) > > My thought is to create a new GLD capability "MC_NO_VLAN_MTU" or > somesuch, which indicates to the framework that full size VLAN frames > are not supported. I'm not sure about the amount of code involved in > making use of his (perhaps simply disallowing such devices to be used > with VLANs altogether?) but I think it would be nice to support. > > I'd like thoughts on this matter.
Sounds like a great idea. With other questions that have come up and many that have not yet, it would be good to be able to get insight into a lot of capabilities of the hardware. Support for: Jumbo Frames (this comes up a lot); if so, max MTU VLAN Large Send Offload; if so, TCP, UDP Checksum offload; if so, ?? Factory MAC addresses; how many, how many not used Hardware classification; if so, are all in use and will adding another force software classification and thus performance degredation. There are probably a number of others. Thanks Steffen > Thanks! > > -- Garrett > _______________________________________________ > networking-discuss mailing list > [email protected] _______________________________________________ networking-discuss mailing list [email protected]
