Date: Wed, 19 Jun 2002 12:25:35 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Julian Elischer <julian@elischer.org> Cc: julian@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: removing global variables from the network stack Message-ID: <20020619122535.A60231@iguana.icir.org> In-Reply-To: <Pine.BSF.4.21.0206191148000.26167-100000@InterJet.elischer.org>; from julian@elischer.org on Wed, Jun 19, 2002 at 11:58:32AM -0700 References: <20020619094420.C58636@iguana.icir.org> <Pine.BSF.4.21.0206191148000.26167-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 19, 2002 at 11:58:32AM -0700, Julian Elischer wrote: ... > Since Archie and I am responsible for this I will that was because you were on the To: list :) > It is not just the divert code, but teh ipfw 'fwd' code also makes use of > a global variable I think. oh yes, i forgot that. > The added information needs to travel with the packet in some way. in general, yes. In these specific cases (ipfw, divert, forward), obviously this is not true because we have a single instance of 3 global variables which are only used while the packet is being processed, not when it resides in some queue. > I suggest that we make use of metadata stored in the m_aux packet to > remove this sort of stuff. Dummynet and ALTQ data as well as firewall > classification information and divert/forward information can be stored in > there if we have a format to do it.. I agree with you (and Sam Leffler, who suggested a similar approach based on the m_tag as in NetBSD) as a long term solution (though I have some concerns on performance, as i mentioned in the dev.summit in february). However, proper handling of m_aux/m_tag chains (just look at Sam's patch) requires quite extensive changes, and I am afraid to break ipv6/kame stuff (which I have no way to test) in the process. I do not see this as a viable solution for RELENG_4. So take my suggestion as a short-term, very little intrusive step towards the correct solution. > > struct m_hdr fake_mbuf; > > what's wrong with a real mbuf? nothing, except that you only use the m_hdr part, and being this a volatile piece of info used just to avoid changing the interface of ip_input() and friends, it is overkill and way too expensive to allocate it with MGET and have to release it a moment after with m_freem(). > (sorry to not be more costructive right now but My head is in teh thread > scheduler of KSE rather than the network stack right now..) don't worry, and thanks for the feedback. I'll try to document what i do so it will be easier to change it when it is needed. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020619122535.A60231>