Date: Wed, 19 Jun 2002 11:58:32 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@icir.org> Cc: julian@freebsd.org, net@freebsd.org Subject: Re: removing global variables from the network stack Message-ID: <Pine.BSF.4.21.0206191148000.26167-100000@InterJet.elischer.org> In-Reply-To: <20020619094420.C58636@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ( <outgoing packet> ) {
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0206191148000.26167-100000>