From owner-svn-src-head@FreeBSD.ORG Fri Mar 12 08:41:46 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 967D31065672; Fri, 12 Mar 2010 08:41:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 6BEDC8FC16; Fri, 12 Mar 2010 08:41:46 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o2C8fiSD009958; Fri, 12 Mar 2010 00:41:45 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 6EF302D6020; Fri, 12 Mar 2010 00:41:43 -0800 (PST) Message-ID: <4B99FE46.6090001@elischer.org> Date: Fri, 12 Mar 2010 00:41:42 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Robert N. M. Watson" 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: svn-src-head@freebsd.org, Qing Li , svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r205024 - head/sys/net X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 08:41:46 -0000 Robert N. M. Watson wrote: > On Mar 12, 2010, at 8:30 AM, Qing Li wrote: > >> I believe what Julian means is the following: >> >> 1. in the driver, I do this >> >> ifp->if_flags |= IFF_KNOWS_LINK_STATE; >> >> 2. In route.h, I do this >> >> if (ifp->flags & IFF_KNOWS_LINK_STATE) && (ifp->if_link_state == >> 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 I think that any driver that can set link stats will set it to 1 or 2 and that we can treat a state of 0 as "I don't know what the heck you are talking about". My comment on a flag for this purpose was in the abstract. I didn't necessarily mean that a particular bit in a particular register be used for this purpose.. The aim is to be able to discern a driver that will not give a useful result and should therefore be assumed to be online at all times. It looks to me that this can be achieved several ways, including looking for the UNKNOWN link state, or adding a bit in the word to indicate it is valid, to adding a bit somewhere else. > > >> -- Qing >> >> >> On Fri, Mar 12, 2010 at 12:26 AM, Robert N. M. Watson >> wrote: >>> 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: >>>> >>>> 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. >>> >>> Today, we support three link state values: >>> >>> 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 */ >>> >>> 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. >>> >>> 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. >>> >>> For the purposes of ECMP, you just need to decide on your policy: map UNKNOWN to either UP or DOWN for your purposes. >>> >>> Robert