Date: Fri, 12 Mar 2010 08:29:35 +0000 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Qing Li <qingli@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r205024 - head/sys/net Message-ID: <EE414C0D-1287-49FE-904B-26C6EE050008@freebsd.org> In-Reply-To: <9ace436c1003120011v3c627aadka2e57615ae01fe6f@mail.gmail.com> References: <201003111756.o2BHukJu042449@svn.freebsd.org> <alpine.BSF.2.00.1003112128020.97017@fledge.watson.org> <9ace436c1003111530s3bd0de9cq451671909fb6aa64@mail.gmail.com> <5ADB6F0D-11F1-4F9F-87A0-64F57063981E@freebsd.org> <9ace436c1003112352l3b2505ceq63d9c78954520497@mail.gmail.com> <A543276F-1982-4F12-B325-7277C2B42C92@freebsd.org> <9ace436c1003120011v3c627aadka2e57615ae01fe6f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >=20 > 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". >=20 > 2. For the existing dated drivers, because that flag bit is never set, > no check is done. >=20 > 3. In the mean time, we try to convert the drivers progressively. >=20 > 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. >=20 > -- Qing >=20 >=20 > On Fri, Mar 12, 2010 at 12:00 AM, Robert N. M. Watson > <rwatson@freebsd.org> wrote: >>=20 >> On Mar 12, 2010, at 7:52 AM, Qing Li wrote: >>=20 >>>> 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? >>>=20 >>> Not sure if I get the assertion suggestion. How would an assertion = help here ? >>=20 >> I think my proposal is similar to what Juli is suggesting: >>=20 >> - 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. >>=20 >> 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). >>=20 >> 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. >>=20 >> Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EE414C0D-1287-49FE-904B-26C6EE050008>