On Mar 12, 2010, at 8:11 AM, Qing Li wrote: > I like Julian's suggestion because it is simple and very low risk. > And there isn't a need to check for interface type any more. > Here is why:
Re-reading this e-mail: perhaps you mean Juli, not Julian? Robert > > 1. The interfaces that are popular and modern are already supporting > link_state. So for these drivers, and there are just a few, I will go set > its if_flags to include "can change link_state". > > 2. For the existing dated drivers, because that flag bit is never set, > no check is done. > > 3. In the mean time, we try to convert the drivers progressively. > > 4. If one wants to do ECMP and not having packets go into a black > hole when the physical link is down, that person can ping the ML > and ask for driver compatibility list. If we haven't converted that > particular driver by then, we will update the driver if it's capable > at that time. > > -- Qing > > > On Fri, Mar 12, 2010 at 12:00 AM, Robert N. M. Watson > <rwat...@freebsd.org> wrote: >> >> On Mar 12, 2010, at 7:52 AM, Qing Li wrote: >> >>>> Is there any way we can pick up via an assertion that an interface driver >>>> has failed to implement this functionality? This has never been a historic >>>> requirement, so I suspect there are a lot of drivers floating around that >>>> fail to meet the requirement. Also, is this for IFT_ETHER only, or also >>>> other link types? >>> >>> Not sure if I get the assertion suggestion. How would an assertion help >>> here ? >> >> I think my proposal is similar to what Juli is suggesting: >> >> - Define a new interface capability for link state detection. >> - If a packet is sent or received on the interface, the capability is set, >> but the link state hasn't been set, panic. >> - If a packet is sent received on the interface, the capability isn't set, >> and the link state has been set, panic. >> >> That way the system blows up nicely and immediately, rather than dhclient >> simply never working, etc. Also, that way, testing for link state support is >> done at a point when we know the interface is live (a packet is sent or >> received). >> >> Finally, it means that code interested in link state isn't testing for one >> of (n) IFT_ types it thinks should have link state, but instead testing >> specifically whether the driver declares link state support. Of course, then >> you have to decide how to behave if a configured interface ECMP is running >> on doesn't support link state: the answer there is probably to assume it is >> always up, which would make this work for all those drivers that current >> fail to implement it. And if the hardware can't support link state, which >> some historic (and perhaps future) link types can't, things still work. >> >> Robert _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
