From owner-svn-src-all@FreeBSD.ORG Fri Mar 12 08:32:25 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53C7D1065670; Fri, 12 Mar 2010 08:32:25 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1168F8FC15; Fri, 12 Mar 2010 08:32:25 +0000 (UTC) Received: from [192.168.2.102] (host86-180-59-125.range86-180.btcentralplus.com [86.180.59.125]) by cyrus.watson.org (Postfix) with ESMTPSA id C516146B53; Fri, 12 Mar 2010 03:32:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <9ace436c1003120030m39f518basc77c7cff40299008@mail.gmail.com> Date: Fri, 12 Mar 2010 08:32:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201003111756.o2BHukJu042449@svn.freebsd.org> <9ace436c1003111530s3bd0de9cq451671909fb6aa64@mail.gmail.com> <5ADB6F0D-11F1-4F9F-87A0-64F57063981E@freebsd.org> <9ace436c1003112352l3b2505ceq63d9c78954520497@mail.gmail.com> <9ace436c1003120011v3c627aadka2e57615ae01fe6f@mail.gmail.com> <8726950E-5110-4FE1-90BB-B4205D637764@freebsd.org> <9ace436c1003120030m39f518basc77c7cff40299008@mail.gmail.com> To: Qing Li X-Mailer: Apple Mail (2.1077) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r205024 - head/sys/net X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 08:32:25 -0000 On Mar 12, 2010, at 8:30 AM, Qing Li wrote: > I believe what Julian means is the following: >=20 > 1. in the driver, I do this >=20 > ifp->if_flags |=3D IFF_KNOWS_LINK_STATE; >=20 > 2. In route.h, I do this >=20 > if (ifp->flags & IFF_KNOWS_LINK_STATE) && (ifp->if_link_state =3D=3D > LINK_STATE_UP) > return 1; Please do *NOT* do this: (1) Do not overload if_flags with more run-time set flags without = well-defined atomicity properties (2) Why isn't LINK_STATE_UNKNOWN already sufficient here? The only change I think would be useful is adding a new IFCAP flag that = allows a driver to statically declare that it will someday set the link = state. But I don't think that helps with ECMP, that's just for the = benefit of programs like dhclient that care about future events rather = than current state. Robert >=20 > -- Qing >=20 >=20 > On Fri, Mar 12, 2010 at 12:26 AM, Robert N. M. Watson > wrote: >>=20 >> On Mar 12, 2010, at 8:11 AM, Qing Li wrote: >>=20 >>> 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: >>>=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 >>=20 >> Today, we support three link state values: >>=20 >> 170 /* >> 171 * Values for if_link_state. >> 172 */ >> 173 #define LINK_STATE_UNKNOWN 0 /* link invalid/unknown = */ >> 174 #define LINK_STATE_DOWN 1 /* link is down */ >> 175 #define LINK_STATE_UP 2 /* link is up */ >>=20 >> I'm confused about Julian's proposal because it seems to me that we = already know when a driver hasn't set or is unable to determine the link = state: it will (should) be set to LINK_STATE_UNKNOWN by default. >>=20 >> So the only question we don't know the answer to, at run-time, is = whether a driver may *ever* set the link state (i.e., it thinks it knows = how to), and hence whether or not tools like dhclient should try to wait = for that to happen. That is the problem that an interface capability = would solve. >>=20 >> For the purposes of ECMP, you just need to decide on your policy: map = UNKNOWN to either UP or DOWN for your purposes. >>=20 >> Robert