> > I'm not sure I understand the motivation. If it's actually true that most > > Ethernet drivers (and not other types of drivers) have a margin of 4, then > > I'm fine with such a change. But doing it just to avoid updating the > > drivers doesn't make sense to me. > > I think I asked for adding a default because from what I read from a few > driver docs (bge, e1000g), it's very hard to determine the margin value. > for these two nics, the margin could be set to any size provided that > the mss register is programmed correctly to accomodate the margin. > > I thought that, for hardware that behave this way, it would be easier > for driver writers to not have to arbitrarily choose a margin size. > the framework could just assume a default of 4 for ethernet. > if we document (whenever gldv3 is made public) that 4 means vlan > support, 0 means lack of it, the driver writer would need to override > the margin value only if he's absolutely sure the nic supports a > non-arbitrary margin > 4, or if vlan is not supported. > > assuming that the majority of gldv3 nics (current and future) support > vlan, what's the risk in assuming a default margin of 4?
My concern is that "margin" is intended to be used for things other than VLANs -- but both by having the margin have a per-mactype-plugin default value, and by having that value default to 4, we're really wiring everything up to be VLAN-specific. (e.g., the only reason why 4 makes sense as the default for Ethernet is because we're assuming that it's being used for VLANs, and VLANs are only supported on Ethernet.) I agree that driver writers will initially puzzle at the "margin" concept, and some may struggle to find an appropriate value. But if we're going to support such a concept (and it seems like it is also useful for RBridges), I think we need to treat it as a first-class entity and expect driver writers to set it correctly so that Solaris can appropriately make use of it both now and in the future. If we instead try to guess a value, I think we will have a tough time supporting anything other than VLANs. In any case, I'd hope this matter isn't a showstopper but if it is please let us know ASAP since any changes here will have testing impact and we're doing testing for final approach now. -- meem
