From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 18:55:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F76E16A4E7; Tue, 4 Jul 2006 18:55:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04C0A43D76; Tue, 4 Jul 2006 18:55:03 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.37]) by a50.ironport.com with ESMTP; 04 Jul 2006 11:55:03 -0700 Message-ID: <44AAB986.2070505@elischer.org> Date: Tue, 04 Jul 2006 11:55:02 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harti Brandt References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> <20060704174208.GA1734@odin.ac.hmc.edu> <20060704195220.K74584@beagle.kn.op.dlr.de> In-Reply-To: <20060704195220.K74584@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, yar@comp.chem.msu.su, rwatson@freebsd.org, freebsd-net@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/sys/net if_vlan.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2006 18:55:16 -0000 Harti Brandt wrote: >On Tue, 4 Jul 2006, Brooks Davis wrote: > >BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: >BD>> In message: <20060703202803.GA22556@odin.ac.hmc.edu> >BD>> Brooks Davis writes: >BD>> : and act as though the interface is not there. We could then consider >BD>> : either holding the interface for a configurable or computed length >BD>> : of time or adding some sort of refcounting (probably impractical). >BD>> >BD>> Refcounting would be good for the 'macro' things (coming and going) >BD>> that are infrequent, but we might have mulitple people doing. You are >BD>> right it likely is too inefficient to do with mbugs. One other option >BD>> might be to have a configurable time after the last time that it was >BD>> accessed via the 'safe' routines that were setup. This way we'd tie >BD>> the removal of the interface to a period of time after it was last >BD>> used, rather than after it was removed. I don't know if such a >BD>> difference would matter much in practice. >BD> >BD>We might get some mielage out of last used, but then we'd have to keep >BD>that timestamp updated. For normal applications, once we've torn down >BD>the sockets and drained their queues, I believe we should not have to >BD>wait more than a few seconds unless dummynet or some other mechanism >BD>that queues mbufs for a significant period of time is enabled. If >BD>dummynet is enabled we need to wait a bit longer, but it isn't outside >BD>the relm of possibility for dummynet to be modified to tell us how long >BD>it will be until the last mbuf it currenly holds will be released. In >BD>practice, 121 seconds is probably a good default number since a 60 >BD>second max RTT is assumed in TCP and thus delays longer than that >BD>would break everything anyway. >BD> >BD>> The only other 'issue' that I see with this approach is if I remove a >BD>> card, and then insert it again before the timeout happens. Does that >BD>> card get a new interface name? And would people care or not... >BD> >BD>The name is unregistered with the call to if_detach because if_detach >BD>removes the interface from the ifnet list. My guess is that >BD>we'll either zero the name field or set to something like _zombie. The >BD>unit will remain reserved until later. We'll need to add an SNMP index >BD>mananaged in userland to satisfy come current if_index consumers. > >bsnmp does this anyway because of the rules for ifIndex. It has some >heuristic to guess whether an interface is a physical one or not and if it >is, it uses the same index again. The downside of this is that the >interface index you see via SNMP has nothing to do with the interface >index you see in the system and this does not work accross reboots and >daemon restarts as required by the RFC. > > > If we had a way to to this in the system (e.g. kept the mac address with the ifnum in a hash) then we could just keep the ifnum in the mbuf instead of the ifp pointer, as that is only occasionally used, and a ifnum2ipf() macro could check the validity wheheve it is used. >harti > >