From owner-freebsd-current Mon Jul 27 22:53:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA07090 for freebsd-current-outgoing; Mon, 27 Jul 1998 22:53:01 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles329.castles.com [208.214.167.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA07085 for ; Mon, 27 Jul 1998 22:52:51 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id WAA00911; Mon, 27 Jul 1998 22:51:13 -0700 (PDT) Message-Id: <199807280551.WAA00911@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Luigi Rizzo 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 ? In-reply-to: Your message of "Tue, 28 Jul 1998 05:50:57 +0200." <199807280350.FAA04809@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jul 1998 22:51:13 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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