From owner-freebsd-net Wed Jun 19 12:25:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id AEB9F37B40E; Wed, 19 Jun 2002 12:25:38 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5JJPZn60481; Wed, 19 Jun 2002 12:25:35 -0700 (PDT) (envelope-from rizzo) Date: Wed, 19 Jun 2002 12:25:35 -0700 From: Luigi Rizzo To: Julian Elischer Cc: julian@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: removing global variables from the network stack Message-ID: <20020619122535.A60231@iguana.icir.org> References: <20020619094420.C58636@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Wed, Jun 19, 2002 at 11:58:32AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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