Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Dec 2001 13:56:42 -0800 (PST)
From:      Julian Elischer <julian@elischer.org>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
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 ? 
Message-ID:  <Pine.BSF.4.21.0112201352110.46573-100000@InterJet.elischer.org>
In-Reply-To: <3481.1008884453@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help


On Thu, 20 Dec 2001, Poul-Henning Kamp wrote:

> 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 ?

That's why I suggest that 'real' devices that run off interrupts set the 
"should queue and leave" flag before passing the packet to the next layer.

It is conceivable that you could have a limit as to how many packet/module
processings you allow a single call to the netgraph code to do. Interrupts
could set it to '6' or something
which would allow the "average" packet to be processed completely.

I know where this would go and it would be easy but I already have the
"queue and return" flag that I use..
(The flag could be replaced by the number, set to '0') :-)



> 
> -- 
> 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
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" 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.0112201352110.46573-100000>