Am 17.03.2014 13:28, schrieb Antti Kantee:
> On 17/03/14 09:07, Martin Unzner wrote:
>>> So, yes, rump_sys_sendto() is designed to be a
>>> drop-in-replacement-with-no-strings-attached for sendto() -- at least
>>> assuming you have the corresponding socket opened ;). Calling
>>> rump_sys_sendto() will be significantly faster if you have curlwp set
>>> (what I call a "bound" thread), but it will work correctly either way.
>> OK, so it would probably not be bad to do something like this in netperf
>> (from your thesis):
>>
>> rump_pub_lwproc_rfork(RUMP_RFCFDG);
>> rump_schedule();
>> for(...) {
>> rump_sys_sendto(...);
>> }
>> rump_unschedule();
>>
>> If I got it right, rump_pub_lwproc_rfork does not perform a fork
>> operation in the host program, but only in the Rump kernel? Do I need to
>> make sure that there are no non-Rump operations before
>> rump_unschedule(), and if so, why? For instance, in your thesis you have:
> Yes, calling rfork is desirable since it creates a bound thread and will
> allow your call to take the fastpath in the scheduler.
>
> No, the rump_schedule() is not needed (or even allowed).
> rump_schedule() is already called by rump_sys_sendto(). Think of it
> this way: rump_schedule() + rump_unschedule() are used to lock a
> resource. Calling mutex_lock() twice without a mutex_unlock() in
> between is illegal, and so is calling rump_schedule() twice. In fact,
> analogy with mutexes goes even further: rump_schedule() reserves the
> resource only the for the calling thread. So if you want to call the
> rump kernel from multiple threads, each thread needs their own
> schedule/unschedule dances.
>
> I'm not sure what "no non-Rump operations" means.
>
> I'd also recommend you to re-read section 2.3 in the blue book. It will
> hopefully make a whole different kind of sense after working with the
> relevant concepts on the implementation level. (I'll be the first to
> admit that it's not very easy to read without prior "hands-on" experience)
It did, _a lot_, thanks for the pointer. According to your statements,
it should be fairly easy to equip netmap with the necessary calls.
>
>> if (mylwp->l_dupfd < 0) {
>> rump_unschedule();
>> errx(1, "open failed");
>> }
>>
>> If you are exiting anyway, would rump_sys_reboot() work instead of
>> rump_unschedule?
> Generally speaking, a test program can give a much more reliable answer
> than any human on this list. After that is done, humans will be more
> efficient in figuring out why or why not.
Yes, well, it's not utterly important -- more of a hypothetical question.
>
>> And another question rather basic question: Is there a prominent use
>> case where I would need multiple lwps in Rump?
> Due to how NetBSD uses kernel threads, quite a few lwps exist right
> after calling rump_init(). I guess that's a fairly prominent use case ;)
>
> Apart from that, what Justin said, though I'd say "concurrent
> operations" instead of "blocking operations" (and they may even be
> parallel operations).
Thank you both for answering, I think I got it now.
Cheers!
Martin
------------------------------------------------------------------------------
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/13534_NeoTech
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
