[somewhat repeating what others said already, hopefully with some new
insight]
On 19/04/14 09:35, Santos Das wrote:
> Before I start, I have a basic question ? Does the current rump kernel
> support multiple processes? As you know, in Nginx we have master process
> which creates several worker process. The master process creates the listen
> socket and all the worker listens to that socket and the synchronization is
> achieved through the mutex.
Well, yes and no ;)
That's actually a fairly difficult question to answer without getting
into much detail. I suggest skimming chapter 2 of the book that Martin
linked.
> Now, can I link the rump kernel to the main process . Since the worker
> processes fork from the parent, they will get the linked rump kernel
> library along with it during the fork system call in their process address
> space.
Right, you can't fork the kernel. It's easy to imagine why not: after a
fork you'd have two network stacks using the same IP addresses. (ok,
strictly speaking, you can fork the kernel, but undesirable things will
happen as a result)
There is a "remote" mode, where the application isn't in the same host
process with the rump kernel and communication is done via IPC. That,
of course, is much slower than a function call. Furthermore, for
userspace, I really wrote it for convenience instead of performance.
I'd say using the remote mode for high performance is sensible only if
using a rump kernel as an offload engine.
So, that leaves threads. Generally, it's not too difficult to replace
fork with pthread_create(). The approximate replacement, off the top of
my head, is something like:
mylwp = rump_pub_lwproc_curlwp();
rump_pub_lwproc_rfork(RUMP_RFFDG);
newlwp = rump_pub_lwproc_curlwp();
pthread_create(..., newlwp);
rump_pub_lwproc_switch(mylwp);
and then in the worker:
rump_pub_lwproc_switch(arg);
[do work]
rump_pub_lwproc_releaselwp();
return NULL;
That dance ensures that you emulate the file descriptor copy properties
of fork().
(see, there is multiprocess support in a rump kernel, just in a slightly
different way. again, see chapter 2)
> The parent process will open the listen 'socket' (here it is no longer a
> socket, just a call to the rump kernel socket abstraction) and do a
> select/epoll/kqueue (again a event loop abstraction). Each forked worker
> process will inherit this listen 'socket'. The zero copy driver will
> deliver packets to a user space fifo which will result in read activity
> notification in the rump kernel select abstraction (this is no different
> from a typical process of getting a packet on the NIC, servicing a network
> hardware interrupt and going through the TCP state machine. Only here all
> that happens in user space and interrupts are replaced by polling the
> FIFO).
>
> Is this supported ? Please let me know if I am wrong in my assumption.
Sockets are sockets, not sure why you don't consider sockets provided by
a rump kernel sockets.
Yes, generally it will work like that, though sockets are of course a
poor abstraction if you want zero-copy.
There's still some planned work to optimize the ingress path; currently,
there's both a "hard" interrupt and a soft interrupt for network packet
delivery. That doesn't really make sense in a rump kernel, since a rump
kernel only supports soft interrupts. I have a plan, just haven't
gotten around to doing the work yet:
https://github.com/rumpkernel/wiki/wiki/Performance%3A-optimizing-networking-performance
(I wrote the page originally for DPDK, but of course the same thing
applies to netmap also)
> Another thing I dont fully understand is how the rump kernel needs to
> interface with the real kernel for other system calls. (system calls like
> gettimeofday(), or fork, setbrk, other timer related calls or file system
> calls) cannot be serviced by the rump kernel since it is only a library and
> it will need to hand it over to the real kernel for all this.
I'm not sure if that's a question or not.
- antti
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
