From owner-freebsd-net Wed Jun 19 12: 0:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by hub.freebsd.org (Postfix) with ESMTP id 9CB5937B403; Wed, 19 Jun 2002 12:00:20 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020619190019.CGAJ1547.sccrmhc02.attbi.com@InterJet.elischer.org>; Wed, 19 Jun 2002 19:00:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA26320; Wed, 19 Jun 2002 11:58:33 -0700 (PDT) Date: Wed, 19 Jun 2002 11:58:32 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: julian@freebsd.org, net@freebsd.org Subject: Re: removing global variables from the network stack In-Reply-To: <20020619094420.C58636@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 19 Jun 2002, Luigi Rizzo wrote: > Hi, > I am trying to cleanup as much as possible the use of global > variables in the network stack, both for code clarity, and > to ease the use of this code in an SMP context. > > The two offenders I am concentrating upon are IPFW/DUMMYNET and DIVERT. > For the former, I am the guilty one:) I know how to fix it. > > For DIVERT, I think this is someone else's code, so here's my > understanding of the problem and proposed fix: Since Archie and I am responsible for this I will speak up.. It is not just the divert code, but teh ipfw 'fwd' code also makes use of a global variable I think. The added information needs to travel with the packet in some way. 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.. > > The global variable in question is "ip_divert_cookie", > declared in ip_divert.c and used to pass the divert port > to divert_packet(), and from div_output() to ip_output()/ip_input() > > For the former the fix is trivial, we just need to add an additional > argument to divert_packet(). > > For the latter, it *would* be easy to add an argument to ip_output() > but if we do not want to change the interface, perhaps the easiest > trick is to pass the annotation in the same way as it is done for > dummynet info, i.e. using a fake mbuf prepended to the actual chain. > Something like this: > > ip_divert.c::div_output() > > ... make ip_divert_cookie a local variable ... > > struct m_hdr fake_mbuf; what's wrong with a real mbuf? fake anythings in the kernel scare me.. > > fake_mbuf.mh_type = MT_DIVERT; > fake_mbuf.mh_next = m; > fake_mbuf.mh_len = ip_divert_cookie; > ... > if ( ) { > error = ip_output(&fake_mbuf, ...); > ... > } else { /* incoming packet */ > ... > ip_input(&fake_mbuf); > } > > ip_output.c::ip_output() > ip_output.c::ip_input() > > ... right after local variables instead of fetching ip_divert_cookie > > if (m->m_type == MT_DIVERT) { > divert_cookie = m->mh_len; > m = m->mh_next; > } > ... continue with regular processing ... > > Does this look right ? > As a matter of fact, ip_input() is used only in a couple of places > so it might be possible to change the interface and add a second > parameter to carry the divert_cookie. However the use of an annotation > block in front of it seems a bit less intrusive and easier to extend > to other annotations we might want to add. I think that it shuld be a real mbuf and it should be using a generic metadata scheme. KAME have given us m_aux.. let's use it. also check the interaction of divert and IP reassembly codes. (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..) Julian > > cheers > luigi > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > -----------------------------------+------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message