TCP/IP stack as single process

Hi,

I would like to know if TCP/IP stack is implemented as a single
process in linux or is it a single task with multiple threads?

I was wondering if it would be a bottle neck for the following
reasons:


1) If an application packet that needs to be sent out is being
processed by TCP or IP and packets are coming in very fast on the n/w
interface. Won't the IP queue be overhwhelmed by incoming packets.
From a design perspective, there seems to be a problem here, but I am
sure there must have been a lot of consideration before making the
single task design choice !


2) What about TCP timers and IP fragmentation timers?
When TCP is processing a packet an IP timer might expire or vice
versa. How does a single task design handle such issues.


Please clarify.

On Jan 22, 5:52*am, "syuga2...@gmail.com" <syuga2...@gmail.com> wrote:

> I would like to know if TCP/IP stack is implemented as a single
> process in linux or is it a single task with multiple threads?

Neither. It's implemented as a large collection of code that is
invoked in all kinds of contexts.

> I was wondering if it would be a bottle neck for the following
> reasons:
>
> 1) If an application packet that needs to be sent out is being
> processed by TCP or IP and packets are coming in very fast on the n/w
> interface. Won't the IP queue be overhwhelmed by incoming packets.
> From a design perspective, there seems to be a problem here, but I am
> sure there must have been a lot of consideration before making the
> single task design choice !

Why would an IP queue for outbound packets have any connection to the
process of sending out a packet? What's the common element that you
think would let one have any effect on the other?

> 2) What about TCP timers and IP fragmentation timers?
> * * When TCP is processing a packet an IP timer might expire or vice
> versa. How does a single task design handle such issues.

There is no "single task design". The network stack isn't a task, it's
a chunk of code that is invoked in many contexts. When an application
wants to send a packet, the application calls into the kernel and then
runs the "send a packet" code. This task runs that code, there is no
"switch over" to some other task -- that would be a pure inefficiency.

DS

On Jan 22, 8:40*pm, David Schwartz <dav...@webmaster.com> wrote:
> On Jan 22, 5:52*am, "syuga2...@gmail.com" <syuga2...@gmail.com> wrote:
>
> > I would like to know if TCP/IP stack is implemented as a single
> > process in linux or is it a single task with multiple threads?
>
> Neither. It's implemented as a large collection of code that is
> invoked in all kinds of contexts.
>
> > I was wondering if it would be a bottle neck for the following
> > reasons:
>
> > 1) If an application packet that needs to be sent out is being
> > processed by TCP or IP and packets are coming in very fast on the n/w
> > interface. Won't the IP queue be overhwhelmed by incoming packets.
> > From a design perspective, there seems to be a problem here, but I am
> > sure there must have been a lot of consideration before making the
> > single task design choice !
>
> Why would an IP queue for outbound packets have any connection to the
> process of sending out a packet? What's the common element that you
> think would let one have any effect on the other?
>
> > 2) What about TCP timers and IP fragmentation timers?
> > * * When TCP is processing a packet an IP timer might expire or vice
> > versa. How does a single task design handle such issues.
>
> There is no "single task design". The network stack isn't a task, it's
> a chunk of code that is invoked in many contexts. When an application
> wants to send a packet, the application calls into the kernel and then
> runs the "send a packet" code. This task runs that code, there is no
> "switch over" to some other task -- that would be a pure inefficiency.
>
> DS

Thanks David!
In VxWorks there is a netTask which handles TCP/IP related work in
addition to the application task.
I think when an application like ftp wants to send data over a TCP
socket, the data gets internally queued on netTask.
This is what I gather from the documentation. Note that there is no
user space-kernel space in Vxworks.
I was wondering how linux handles this. From your explanation it seems
like for an application like ftp, the TCP timers are
implemented in ftp process context.

But, what about a router (on linux) which does not have an
application, but rather only IP and data link layers.
In what process context would function calls to IP and other layers be
made? This is adding to my confusion...

Please clarify.
Thanks,
syuga

On Jan 23, 6:16*am, "syuga2...@gmail.com" <syuga2...@gmail.com> wrote:

> I was wondering how linux handles this. From your explanation it seems
> like for an application like ftp, the TCP timers are
> implemented in ftp process context.

No. The timers are implemented purely by the kernel. There is no
reason to switch to the FTP process context to run the timers. That
would be a waste.

> But, what about a router (on linux) *which does not have an
> application, but rather only IP and data link layers.
> In what process context would function calls to IP and other layers be
> made? This is adding to my confusion...

None. A particular process context is not needed to make calls into
the kernel's TCP stack. In general, whatever context the system
happens to be in will be the context the code will run in, since the
code doesn't care about its context -- it only cares about kernel
state, which is context-independent.

Some code may be run by a kernel thread, which requires a switch to
the kernel thread. But, oddly, in Linux this doesn't change the
process context. It's still arbitrary -- whatever context happened to
be running.

The intent is to make the code fast. Why bother switching to a
particular process context when the TCP connection isn't necessarily
associated with any particular process?

DS