Re: Receiving Network Packets with Mirage/kFreeBSD

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

out of curiosity, and from a *very* naive viewpoint (so feel free to explain 
why this is a dumb question), how applicable would the same structures be to 
supporting disk/other io access?

(i don't have a particular use-case in mind, just asking.)

On 16 Aug 2012, at 16:13, PALI Gabor Janos wrote:

> Hello there,
> 
> For your information, I have just added support for receiving network packets
> to the kFreeBSD backend of mirage-platform:
> 
> https://github.com/pgj/mirage-kfreebsd/commit/c10b740218fd0af10e7b8e424d4cdde191edb251
> 
> Note that there is also a basic/netif test added to mirage-test/regress to
> try this out and see it in action.
> 
> I would like to call for your reviews and comments.  To narrate on the design
> choices I made, here is a brief summary on how the current implementation
> looks like at the moment.
> 
> - After loading the built kernel module and starting up the evaluation of
>  the Netif.create function, Mirage asks for a list of available Ethernet
>  interfaces from the FreeBSD kernel and then assigns an lwt thread to each of
>  them by "plugging".
> 
> - Plugged interfaces are stored in a linked list and have their ng_ether(4)
>  hook (called from ether_input()) activated and pointed to
>  netif_ether_input().  At the same time, there is a shared ring buffer
>  created for each of them in Mirage then passed to the C function
>  responsible for administering the list of plugged interfaces,
>  caml_plug_vif().
> 
> - Shared ring buffers are created as Io_pages by allocating page-aligned,
>  contiguous, multi-page memory areas via FreeBSD's contigmalloc(9).  These
>  are directly accessible in Mirage as character arrays.
> 
> - Each shared ring buffer is currently of size 33 pages, and operates with
>  2048-byte slots.  The buffers start with a header that maintains all the
>  required meta information, like next position, available items, size of
>  stored items.
> 
> - Each packet arriving on any of the plugged interfaces is placed to the next
>  available slot of the corresponding shared ring buffer with m_copydata().
> 
> - In parallel with this in Mirage, the rx_poll function is run in loop that
>  polls for available packets in the shared ring buffer.
> 
> - When rx_poll finds unprocessed packets then it runs the user-specified
>  function on them, e.g. print the size of the packet in basic/netif.  It is
>  implemented by passing a view on the Io_page, i.e. without copying.  After
>  the user function has finished, the packet is removed from the ring.
> 
> - When no packets are available on the polled interface, rx_poll sleeps for a
>  millisecond.
> 
> - Mirage is stopped when the kernel module is unloaded, which also involves
>  unplugging the interfaces.
> 
> Let me add that shared rings do not do locking at the moment, but if you are
> happy with the design I could proceed with implementing it.  (However, I am
> not completely sure how to share locks between OCaml and C.)
> 


-- 
Cheers,

R.




This message and any attachment are intended solely for the addressee and may 
contain confidential information. If you have received this message in error, 
please send it back to me, and immediately delete it.   Please do not use, copy 
or disclose the information contained in this message or in any attachment.  
Any views or opinions expressed by the author of this email do not necessarily 
reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.