Is TCP/IP stack intr-driven resource hog ? - Networking

This is a discussion on Is TCP/IP stack intr-driven resource hog ? - Networking ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Is TCP/IP stack intr-driven resource hog ?

  1. Is TCP/IP stack intr-driven resource hog ?

    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








  2. Re: Is TCP/IP stack intr-driven resource hog ?

    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.

  3. Re: Is TCP/IP stack intr-driven resource hog ?

    Maxwell Lol 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...

+ Reply to Thread