On Sat, Apr 19, 2014 at 10:35 AM, Santos Das <[email protected]> wrote: > Hi, > > I am trying to use rump kernel for Nginx. The motivation for me to use the > TCP stack in user space to achieve higher performance. Not sure if someone > has already done it ? Any pointers on this would be of much help to us.
I don't think anyone has tried yet... > 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. No, the rump kernel only supports single processes. You can have multiple threads. This is one of the reasons I have not really looked at Nginx, as it seems to require multiple processes as part of the architecture. > 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. That is not going to work, as the rump kernel is multithreaded and needs to do synchronisations. > 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. If you can persuade Nginx to work with threads rather than processes, or if you can make it run over TCP sockets (so each process has its own rump kernel) then this might work. I would be more inclined to start with a different evented http server, maybe based on libev/libuv, rather than Nginx... > > 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. There are now time and timer calls in the rump kernel. Otherwise if you are using the rumprun https://github.com/rumpkernel/rumprun build model you can add extra host syscals via emul.c to cover for the missing ones. Justin ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
