On Sun, Nov 25, 2012 at 10:53 AM, Reyk Floeter <[email protected]> wrote: > Am Sonntag, 25. November 2012 schrieb Brad Smith : >> >> I don't think you're understanding what I am trying to say. I am not >> switching >> or removing anything per se. The MII framework already takes care of this >> and >> has for 12 years now. Any driver using the MII framework does have the >> baudrate >> set as the current link bandwidth. I am just removing an assumed initial >> baudrate >> value which the MII framework will end up overwriting anyway. This is how >> some >> of the most common drivers such as em, bge, bnx, re, fxp, etc. have done >> things >> for many many years if not over a decade. >> >> > Ok, understood. I was mixing up if_media with MII. But I'm still not sure > if it is the best solution to set the initial baudrate to 0. Maybe it > should default to the _maximum_ link speed instead. Having an initial > baudrate of 0 on boot before the link is established might cause an impact > on at least bridge, trunk lacp and altq bandwidth. Maybe downgrading the > baudrate would be better than upgrading. > > Reyk > >
i agree with brad that setting baudrate to any value during attach is kinda pointless, but i don't want the interface to freak bridge or trunk out because they depend on such behavior. so i wonder: are you sure that trunk, bridge and altq expect a non zero baudrate right from the start and won't update their states once it changes? for example bge doesn't set baudrate during attach and updates it when interrupt fires. does it exhibit the problem you mentioned?
