From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 19:02:39 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 C78DD16A4E1; Tue, 4 Jul 2006 19:02:39 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id B75A443D70; Tue, 4 Jul 2006 19:02:33 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 21:02:32 +0200 Date: Tue, 4 Jul 2006 21:02:32 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Julian Elischer In-Reply-To: <44AAB986.2070505@elischer.org> Message-ID: <20060704205916.X74584@beagle.kn.op.dlr.de> 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> <44AAB986.2070505@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 04 Jul 2006 19:02:32.0400 (UTC) FILETIME=[67555D00:01C69F9C] 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 Reply-To: Harti Brandt 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 19:02:40 -0000 On Tue, 4 Jul 2006, Julian Elischer wrote: JE>Harti Brandt wrote: JE> JE>> On Tue, 4 Jul 2006, Brooks Davis wrote: JE>> JE>> BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: JE>> BD>> In message: <20060703202803.GA22556@odin.ac.hmc.edu> JE>> BD>> Brooks Davis writes: JE>> BD>> : and act as though the interface is not there. We could then JE>> consider JE>> BD>> : either holding the interface for a configurable or computed length JE>> BD>> : of time or adding some sort of refcounting (probably impractical). JE>> BD>> BD>> Refcounting would be good for the 'macro' things (coming and JE>> going) JE>> BD>> that are infrequent, but we might have mulitple people doing. You are JE>> BD>> right it likely is too inefficient to do with mbugs. One other option JE>> BD>> might be to have a configurable time after the last time that it was JE>> BD>> accessed via the 'safe' routines that were setup. This way we'd tie JE>> BD>> the removal of the interface to a period of time after it was last JE>> BD>> used, rather than after it was removed. I don't know if such a JE>> BD>> difference would matter much in practice. JE>> BD> JE>> BD>We might get some mielage out of last used, but then we'd have to keep JE>> BD>that timestamp updated. For normal applications, once we've torn down JE>> BD>the sockets and drained their queues, I believe we should not have to JE>> BD>wait more than a few seconds unless dummynet or some other mechanism JE>> BD>that queues mbufs for a significant period of time is enabled. If JE>> BD>dummynet is enabled we need to wait a bit longer, but it isn't outside JE>> BD>the relm of possibility for dummynet to be modified to tell us how long JE>> BD>it will be until the last mbuf it currenly holds will be released. In JE>> BD>practice, 121 seconds is probably a good default number since a 60 JE>> BD>second max RTT is assumed in TCP and thus delays longer than that JE>> BD>would break everything anyway. JE>> BD> JE>> BD>> The only other 'issue' that I see with this approach is if I remove a JE>> BD>> card, and then insert it again before the timeout happens. Does that JE>> BD>> card get a new interface name? And would people care or not... JE>> BD> JE>> BD>The name is unregistered with the call to if_detach because if_detach JE>> BD>removes the interface from the ifnet list. My guess is that JE>> BD>we'll either zero the name field or set to something like _zombie. The JE>> BD>unit will remain reserved until later. We'll need to add an SNMP index JE>> BD>mananaged in userland to satisfy come current if_index consumers. JE>> JE>> bsnmp does this anyway because of the rules for ifIndex. It has some JE>> heuristic to guess whether an interface is a physical one or not and if it JE>> is, it uses the same index again. The downside of this is that the JE>> interface index you see via SNMP has nothing to do with the interface index JE>> you see in the system and this does not work accross reboots and daemon JE>> restarts as required by the RFC. JE>> JE>> JE> JE>If we had a way to to this in the system (e.g. kept the mac address JE>with the ifnum in a hash) then we could just keep the ifnum in the mbuf JE>instead of the ifp pointer, as that is only occasionally used, and a JE>ifnum2ipf() macro could check the validity wheheve it is used. This would be helpful for the SNMP daemon, because this would also allow to reuse the ifnum if the same interface is plugged in back. However care must be taken that non-physical interfaces get a new ifnum always (iftun for example). harti