13:28 <azure_balls> Hey everyone, I'd like to make a Mirage unikernel with two network interfaces, but am not super familiar with OCaml, and given the lack of documentation (that I can find), I can't see how I could do this. A big part of the problem is I don't understand how Mirage sets up the network interfaces--it *seems* Mirage assumes only one interface will eve

13:28 <azure_balls> r be present. Is this true? Can I simply manually edit the generated main.ml and change the type of my Main.start to accept two NETWORK parameters?

14:21 <hannes> azure_balls: best ask on the mailing list http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

14:22 <azure_balls> Roger that...

14:27 <hannes> azure_balls: I'm sure it is possible to attach two network devices, but I never did (and don't know off hand where an example would be)

14:48 <azure_balls> hannes: yes, http://www.openmirage.org/graphics/mirage-sample-application.png makes it seem very modular, and like I should be able to have multiple network interfaces without much trouble. Of course, my problem is with actually *realizing* this: how can I get my unikernel to accept more than one NETWORK device as a parameter, and how to configure

14:48 <azure_balls> the generated main.ml (so: not even 'full automation' with Mirage) to create two NICs and pass them to the unikernel

15:34 <jgjl> hi, azure_balls and hannes, having multiple network devices is also an important use case for me

15:35 <jgjl> are there any plans to support more complex network configurations?

15:36 <jgjl> mirageos is a compelling plaform for Network Function Virtualization (NFV), which requires more than one network interface in most cases

15:37 <azure_balls> jgjl: currently writing a mail to the mailing list about this; give me a few minute to make sure my question(s) is/are precise and I'll send you a draft to see if you can answer anything, and if not, then I'll send it

15:38 <jgjl> azure_balls: nice, are you also working on NFV?

15:41 <azure_balls> I suppose you could say that

15:41 <azure_balls> not really

15:42 <azure_balls> I want to integrate Mirage unikernels into Qubes. One use case, which is the proof-of-concept I'd like to create now, is to use these unikernels as pluggable, composable network filters

15:42 <azure_balls> so, if that's considered NFV, then yes :)

15:44 <azure_balls> (and by a few minutes, I mean more like an hour)

15:47 <jgjl> mhh not really :)

15:47 <jgjl> sound interesting though

15:53 <azure_balls> Is there even any documentation for the network module?

16:46 <azure_balls> jgjl: 1 hour has now become more like 6 hours ;) sorry

18:57 <nojb> If I understand correctly, Io_page allocates memory in chunks 4096 bytes long. I get the impression that one is supposed to use [Io_page.get] instead of [Cstruct.create] to allocate Cstructs. But isn't this a waste of memory ? For example, in `mirage-tcpip', a whole 4K page is allocated to store the *header* of each outgoing IP packet, which is around 20-40 bytes long ...

21:05 <azure_balls> nojb: I'm not familiar enough with the codebase, but Xen only allows page-based (e.g. 4K sized) granularity in the grant tables, so if you're reading/writing data from the environment, you will use 4K no matter what. But I'm not sure why it would need 4K just for the header itself...

21:11 <nojb> azure_balls: thanks for the info - will look into it!