From owner-svn-src-head@FreeBSD.ORG Fri Mar 12 08:11:15 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 94EE4106567D; Fri, 12 Mar 2010 08:11:15 +0000 (UTC) (envelope-from tomelite82@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.221.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0BDCF8FC2F; Fri, 12 Mar 2010 08:11:14 +0000 (UTC) Received: by qyk5 with SMTP id 5so1068384qyk.13 for ; Fri, 12 Mar 2010 00:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=xj3LhsC99EWO8/62co+Dj4hLAIR5kQWffV6zJgJjog8=; b=ACVxbzSUfe8n7cWmKdqqGyl68+CRXSelFKG4ZWsVGHChiFW2WRfNWs2ChTtHkF7bYr wwnCBytqd9EO0t5CIlguX5XfjDfOfhK7sGA6vgEdNtMX3o97B3VptZfe2HH/vYe+sJVe QrRS6kAG06JDo7oiLAAuTHbOb4LIXItpJYwf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=kC7/X+k5nWpmS0tk4ALKbI88OAO7CN8Dk6FySayQv0mIbGbONaGREsjUjO0nQTj6fd SfoNHvDA2shvHTX7kkc3Dpe3vQRP66BDAeaf+8e/iWuqvXTLeTuahVDvtkeLUIfEzSt0 IvRg1mUFqy3Sy25K0zu7d1XYvbmt/4aw6gGNI= MIME-Version: 1.0 Sender: tomelite82@gmail.com Received: by 10.220.122.15 with SMTP id j15mr879038vcr.150.1268381474217; Fri, 12 Mar 2010 00:11:14 -0800 (PST) In-Reply-To: References: <201003111756.o2BHukJu042449@svn.freebsd.org> <9ace436c1003111530s3bd0de9cq451671909fb6aa64@mail.gmail.com> <5ADB6F0D-11F1-4F9F-87A0-64F57063981E@freebsd.org> <9ace436c1003112352l3b2505ceq63d9c78954520497@mail.gmail.com> Date: Fri, 12 Mar 2010 00:11:14 -0800 X-Google-Sender-Auth: 4537e647d5cf592b Message-ID: <9ace436c1003120011v3c627aadka2e57615ae01fe6f@mail.gmail.com> From: Qing Li To: "Robert N. M. Watson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-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:11:15 -0000 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 s= et 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 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 driv= er has failed to implement this functionality? This has never been a histor= ic requirement, so I suspect there are a lot of drivers floating around tha= t fail to meet the requirement. Also, is this for IFT_ETHER only, or also o= ther 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 on= e of (n) IFT_ types it thinks should have link state, but instead testing s= pecifically 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 i= s 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 s= ome historic (and perhaps future) link types can't, things still work. > > Robert