Re: [MirageOS-devel] Many-core ARMv8, Mirage & Networking

[Nik Sultana <ns441@xxxxxxxxx>]

Resending since I'm told it didn't make to the mailing list, perhaps 
there's been some outage.
On 2017-02-03 19:05, Nik Sultana wrote:
> Hi Chris, pls see below regarding Flick.
>
> On 2017-02-03 11:02, Chris Fegan wrote:
> [snip]
> > * Are the Flick tools available in source code to study?
> Yes: https://github.com/NaaS/motto
> Please feel free to add issues/PRs if you come across anything that
> needs improving/fixing.
>
> > * Do you think that Flick will need to remain outside of the Mirage &
> > OCaml ecosystem to make use
> > of multicore & DPDK or can you see a path bring it "into the fold"?
> [snip]
>
> Flick programs can be run using an interpreter written in pure OCaml
> -- to see which packages are required to run this, pls see this line:
> https://github.com/NaaS/motto/blob/master/build.sh#L22
> Thus integrating the OCaml-written Flick runtime into other OCaml
> projects should be straightforward, as far as dependencies go,
> bringing Flick into Mirage's fold as you say but not relying on
> mTCP/DPDK.
>
> Dependencies are the easy bit, but I expect that Flick-on-Mirage would
> involve two trickier bits: resources and concurrency. Regarding
> resources, to make fuller use of Flick on Mirage you'd need to wire up
> Mirage's network stack to Flick's channel interface. This is likely to
> be tricky initially, to harmonise the configuration info presented to
> Mirage and Flick, but as a rough guide you can look at how Unix FIFOs
> are wired to this interface:
> https://github.com/NaaS/motto/blob/master/runtime/resource_instances.ml#L558
> and used here:
> https://github.com/NaaS/motto/blob/master/tests/runtime/forwarder.ml
>
> One would also need to sheaf Flick's concurrency monad with that used
> in Mirage (lwt IIRC) to avoid Flick blocking Mirage. One idea for
> achieving this involves having a non-terminating "thread" started in
> Flick's runtime to hand back control to lwt controlling the Mirage
> appliance, which in turn would eventually pass control to the Flick
> runtime. This is likely to require subtle coding to get going, but I
> think it could be approached as follows: use a fixed and
> non-terminating Flick program consisting of 2 processes exchanging a
> unit value over a channel (i.e.,
> https://github.com/NaaS/motto/blob/master/tests/flick_code/process_pair.cp
> which can be run as shown at
> https://github.com/NaaS/motto/blob/master/tests/runtime/runtime_general_test.ml#L182)
> to develop the composition of the two monad implementations, and once
> this is working I'd black-box the monads' composition and try running
> more kinds of Flick programs.
>
> Because of the centrality of concurrency to both Flick and Mirage
> (particularly wrt networking) I'd start by sorting out the interfacing
> of concurrency monad implementations they use, and then turn to wiring
> up the networking stack.
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel