Re: Receiving Network Packets with Mirage/kFreeBSD

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 22 Aug 2012, at 00:43, "Robert N. M. Watson" <robert.watson@xxxxxxxxxxxx> 
wrote:
> 
>> - 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().
> 
> The pfil(9) KPI in FreeBSD defines 'PFIL_TYPE_IFNET ' but doesn't implement 
> it -- but it sounds like that is what Mirage/kFreeBSD wants. It might be 
> worth implementing it and seeing if ng_ether(4) can also register using the 
> same mechanism.

I'd completely forgotten about netgraph. ng_ether(4) and ng_socket(4) might be 
very useful indeed for ongoing prototyping.

>> - 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.
> 
> For the kernel OCaml stack, is physically contiguous memory required? 
> Normally the FreeBSD VM system will return virtually (and likely physically) 
> contiguous memory for kernel memory allocations, but allowing it to use 
> physically non-contiguous memory gives the VM system flexibility. I.e., is 
> there a reason not to just use malloc(9), which for large allocation sizes, 
> simply requests pages from the VM system rather than using the slab allocator?
> 

The OCaml heap memory does not need to be physically contiguous.  Heap extents 
are allocated in megabyte-ish chunks and tracked using a sparse hashtable in 
memory. However, Io_pages are addressed from within OCaml as a normal array, 
and so do need to virtually contiguous (but not necessarily physically unless 
required by the DMA subsystem).

-anil