From owner-freebsd-arch  Thu Dec 20 13:42:52 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
	by hub.freebsd.org (Postfix) with ESMTP
	id 859CD37B417; Thu, 20 Dec 2001 13:42:48 -0800 (PST)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBKLerl03483;
	Thu, 20 Dec 2001 22:40:53 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Julian Elischer <julian@elischer.org>
Cc: John Baldwin <jhb@FreeBSD.org>, arch@FreeBSD.org,
	Alfred Perlstein <bright@mu.org>
Subject: Re: Kernel stack size and stacking: do we have a problem ? 
In-Reply-To: Your message of "Thu, 20 Dec 2001 13:26:08 PST."
             <Pine.BSF.4.21.0112201322070.46573-100000@InterJet.elischer.org> 
Date: Thu, 20 Dec 2001 22:40:53 +0100
Message-ID: <3481.1008884453@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

In message <Pine.BSF.4.21.0112201322070.46573-100000@InterJet.elischer.org>, Ju
lian Elischer writes:
>> 
>> Now, module 1 sends a request down through module 2 which takes the
>> long path and consequently ends up being queued a module 3.  We
>> unwind/return back up through module 2 and module 1 issues another
>> request which happens to take the short path through module 2 and
>> consequently directly calls into module 3.
>
>NO, because once an item is queued, all requests will queue behind it
>until the queue is drained again.
>
>What may happen in fact is that packet 2 will be queued and packet 1 
>dequeued and processed, followed by packet 2 being dequeued and processed.
>packet 3 may now proceed straight through..

Ahh, but now we hit the next problem:  For stupid congestion reasons
we have N requests queued, and then we happen to come around with N+1
while in an interrupt context and it gets to do all the work...

We wouldn't want subject our interrupt contexts to risk that, would we ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message