Date: Mon, 27 Jul 1998 22:51:13 -0700 From: Mike Smith <mike@smith.net.au> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: julian@whistle.com (Julian Elischer), mike@smith.net.au, wollman@khavrinen.lcs.mit.edu, current@FreeBSD.ORG Subject: Re: SMP kernels... how many processes can be in ? Message-ID: <199807280551.WAA00911@antipodes.cdrom.com> In-Reply-To: Your message of "Tue, 28 Jul 1998 05:50:57 %2B0200." <199807280350.FAA04809@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> > trouble is that there needs to be some place to store data
> > on a 'packet by packet' basis, The data is generated at one point in
> > processing and needed at another..
> > but what if the packet gets queued in between?
>
> that's a minor problem in a sence because the queue must have room for
> the additional info in whatever form you need.
>
> > and how do you pass the information into (for example ip_input())
> > a function when the arguments of that function are alread defined and well
> > known. What ever solution you have should be extensible so as to be used
> > by as-yet un-thought-of users.
>
> my idea (similar in principle to the mbuf one you propose) is to
> adopt one (or a set) of special structs which the caller fills up with
> all parameters it needs. The called function (say ip_input in this
> case) first checks its args and if they correspond to the special
> struct then operates specially. Something like
>
> struct xyz_parms {
> T a ;
> T2 b ;
> struct mbuf *m ;
> } xyz_arg ;
>
> In the caller:
>
> ...
> xyz_arg.m = m ;
> xyz_arg.a = ... '
>
> ip_input ( struct mbuf *)&xyz_arg );
>
> in the called fn:
>
> ip_input(struct mbuf *m)
> {
>
> if (m == (struct mbuf *)&xyz_arg ) {
> struct xyz_parms *p = (struct xyz_parms *)m ;
>
> m = p-> m ;
> /* do special processing with p->a */
> }
> ...
>
> My problem is, do we have multiple instances of the kernel running in
> parallel, so that i need an array of xyz_arg[], one per CPU ? And if
> this is the case, how do i know the CPU i am running on, so that i can
> assign the right xyz_arg[i] without having to use locks to allocate
> them ?
Given that what you're trying to do is pass state with the packet(s)
that you're putting onto the queue, rather than associate state with a
particular quantum of execution in the kernel space, wouldn't it make
more sense to queue a non-IP control packet to pass your state around?
This would allow, eg. for kernel preemption between the 'first' and
'second' functions, and keeps the state in question associated with the
packet(s) rather than in some global variable.
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mike@smith.net.au
\\ The race is long, and in the \\ msmith@freebsd.org
\\ end it's only with yourself. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807280551.WAA00911>