On 22/06/14 23:08, Justin Cormack wrote: >>> Why not? >>> 1. No parallelism. The NetBSD network stack is being made much for >>> multi processor friendly, so you might lose performance. >> >> I still think that if you can partition the network correctly, running n >> networking stacks on 1 core each is faster than 1 stack on n cores. > > Yes I think so, with modern hardware you can create virtual network > devices or queues on demand, with the expected model being one per > core to avoid lock contention anyway, so this fits very well.
You still need one address per networking stack, which is a shoe that might not fit. Though, given rumprun was possible, I'm sure you can figure out a way to cram multiple networking stacks into one process for some clever multiplexing ;) >>> 2. Some stuff missing - I deleted eg the block device driver as it was >>> using threads, daemonize support etc. These are intended to be put >>> back, they just need some thought and were optional so were >>> temporarily removed. >> >> For bio you can just delete half and run everything in the caller's >> context. It won't be efficient, but it'll at least work. >> (not that the bio stuff still is very efficient even with threads) > > It is probably worth integrating polling of io into the (currently > very dumb) scheduler. Using the friendly aio interface? ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
