Date: Tue, 04 Jul 2006 11:55:02 -0700 From: Julian Elischer <julian@elischer.org> To: Harti Brandt <harti@freebsd.org> Cc: src-committers@freebsd.org, yar@comp.chem.msu.su, rwatson@freebsd.org, freebsd-net@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/sys/net if_vlan.c Message-ID: <44AAB986.2070505@elischer.org> In-Reply-To: <20060704195220.K74584@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <brooks@one-eyed-alien.net> 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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44AAB986.2070505>