Re: Reqst for Information: Loopback device programming
From: Peter T. Breuer (ptb_at_lab.it.uc3m.es)
Date: 04/21/05
- Next message: Peter T. Breuer: "Re: Reqst for Information: Loopback device programming"
- Previous message: Peter T. Breuer: "Re: Reqst for Information: Loopback device programming"
- In reply to: Kasper Dupont: "Re: Reqst for Information: Loopback device programming"
- Next in thread: Kasper Dupont: "Re: Reqst for Information: Loopback device programming"
- Reply: Kasper Dupont: "Re: Reqst for Information: Loopback device programming"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 21 Apr 2005 11:30:50 +0200
Kasper Dupont <kasperd@daimi.au.dk> wrote:
> "Peter T. Breuer" wrote:
> > I don't particularly know why the actual network data
> > transmission is done in kernel space rather than userspace.
>
> Performance would be one possible reason. Unfortunately
I don't think it is unless network is very fast indeed .. if requests
are aggregated they may be up to say 128K in size, which on a 100BT
network is about 1/80s (12.5ms) to transmit. Surely the context switch
will not be significant? And then there is the cost of getting the data
to the socket ... hmm, I guess that is a real saving if one passes the
request buffer directly as the socket data, instead of passing it to
and from userspace.
(but if I recall correctly, enbd registers a buffer in the kernel, and
uses that for transfers, so perhaps it manages to avoid the problem).
> it looks like all the work is done in the context of a
> user process. So even though it happens in kernel mode,
> you don't get the performance benefit of lazy mm switching.
>
> Would be interesting to see if performance improvement
> could be achieved by daemonizing the process. I guess it
> is going to crash on return if you do that, so if it
> really makes a significant difference it should probably
> be done right by starting a new kernel thread.
>
> > In this case "don't use a congested network and keep blocksize at 1K to
> > avoid tcp fragmentation" would work.
>
> Do you mean IP fragmentation or TCP segmentation?
Good point. There I meant (if I meant anything) "IP fragmentation", but
of course I was merely thinking of whatever might make buffers
necessary in tcp - out-of-order transmissions, and so on.
Peter
- Next message: Peter T. Breuer: "Re: Reqst for Information: Loopback device programming"
- Previous message: Peter T. Breuer: "Re: Reqst for Information: Loopback device programming"
- In reply to: Kasper Dupont: "Re: Reqst for Information: Loopback device programming"
- Next in thread: Kasper Dupont: "Re: Reqst for Information: Loopback device programming"
- Reply: Kasper Dupont: "Re: Reqst for Information: Loopback device programming"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|