Re: Reqst for Information: Loopback device programming

From: Peter T. Breuer (ptb_at_lab.it.uc3m.es)
Date: 04/21/05


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



Relevant Pages

  • Re: Communications kernel -> userland
    ... >> you're already dealing with network code, you probably don't want to drag ... userland network code prototyping. ... pushed down to BPF using a partial network stack in userspace. ... with the FreeBSD kernel code, not to mention easier on debugging. ...
    (freebsd-hackers)
  • Re: Communications kernel -> userland
    ... +> userland network code prototyping. ... +> pushed down to BPF using a partial network stack in userspace. ... +> with the FreeBSD kernel code, not to mention easier on debugging. ...
    (freebsd-hackers)
  • Re: A kexec approach to hibernation
    ... selective about how network connections are handled. ... from that of the kernel being hibernated. ... encrypted devices and network connections & configuration. ... with a fully functional userspace isn't possible. ...
    (Linux-Kernel)
  • Re: [RFC][PATCH 0/6] Critical Page Pool
    ... it isn't userspace that is determining *which* allocations are ... > critical to the kernel. ... > flag throughout the networking code to take advantage of this pool. ... >> network" which is way too much. ...
    (Linux-Kernel)
  • Re: Reqst for Information: Loopback device programming
    ... |> Kasper says the kernel does the work on the network. ... | transmission is done in kernel space rather than userspace. ... So does enbd just set up a TCP connection between the kernel and ...
    (comp.os.linux.development.system)