With a hardware background, I can just think
completely in the 'virtual' mode.

A single CPU seems to have a lot to do, to process
and pass packages up and down the 7-stage stack.

Q - is it all interrupt driven ?

Like for incoming [for a dialup modem]:
* serial port register=full & needs to be fetched = intr1;
* calls lowest level of stack to get and process
which does intr2 when done;
* calls next level of stack to get and process
which does intr3 when done;
* ...........

? and each level's routine is intr-disabled for a
specific time, by a timer which has a higher
priority than intr1, intr2 ... ?

? and the bytes have to percolate up several levels
before the stack can detect that a valid IP & port
is being addressed ?

Surely not ?

This would be an intollerable resource hog ?

Thanks for any info.

== TIA

nospam@isp.com writes:

> With a hardware background, I can just think
> completely in the 'virtual' mode.
>
> A single CPU seems to have a lot to do, to process
> and pass packages up and down the 7-stage stack.


There is a paper that says the number of instructions needed to
process a packet in minimal


[7] D. Clark, V. Jacobson, J. Romkey, and H. Salwen. An Analysis of
TCP processing overhead. IEEE Communications, June 1989.

I don't know the number, but think it's about 20.

I took a course from Dave Clark years ago, and most of the time is
spent copying data. If you can minimuze the number of times a block
of data has to be copied, the better.

Also - for best performance, you want to use large blocks of data. If
the packets are small, then the network time will be significant -
more than the CPU.


> Q - is it all interrupt driven ?

Yes.

Classic unix systems used a astrcture called "mbufs" that were blocks
of memory that stored data. Pointers to the mbufs were passed around
instead of copying data.


>
> Like for incoming [for a dialup modem]:
> * serial port register=full & needs to be fetched = intr1;
> * calls lowest level of stack to get and process
> which does intr2 when done;
> * calls next level of stack to get and process
> which does intr3 when done;
> * ...........

I will talk about Unix systems. Linux systems have evolved, and I'm
not sure of the internals. But I am sure they have only improved on
what I am describing.

So first the interupt service routines process the data at the
hardware level. Data is stored in mbufs. Some things might be
rescheduled after this, but for now assume the system returns to what
it was doing before the interrupt.

Then the clock ticks. This can be 60, 100, or 1000 times per second.
At this interrupt, the system switches to kernel mode.




Each process has a context, and the system switches contexts as quick
as possible. The kernel knows which of these processes are "ready to
run" (they are not waiting for I/O) and which processes are waiting
for I/O to complete.

If the kernel can do things in kernel mode that is internal
housekeeping, it does. It can come in, see that one and only one
process it ready to run (because the I/O data arrived), the kernel
passes control to this process.

If that process blocks because it does an I/O, the kernel wakes up and
tries to run the next ready-to-run process. If everything is waiting
for I/O to complete, the system idles.


Once it a while the system changes priorities so that all processes
run.

> ? and the bytes have to percolate up several levels
> before the stack can detect that a valid IP & port
> is being addressed ?


When an application opens a port, the kernel knows which ones are
open. It will handle errors when necessary. The application just
knows when data arrives.

Maxwell Lol <nospam@com.invalid> wrote:
> There is a paper that says the number of instructions needed to
> process a packet in minimal


> [7] D. Clark, V. Jacobson, J. Romkey, and H. Salwen. An Analysis of
> TCP processing overhead. IEEE Communications, June 1989.

> I don't know the number, but think it's about 20.

Those were the instructions to process a simple (no window scaling?)
TCP segment, and was IIRC the instructions for TCP. At the risk of
chewing on my feet, that didn't include sockets, IP, driver, interrupt
code, IO services etc.

No actual TCP stack comes close to that ideal few instructions per
segment.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...