[MirageOS-devel] error handling in encode functions

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

Hello,

when I read through some network code (I'm only talking about layers IP
and below), I encountered these signatures:

val into_cstruct : t -> Cstruct.t -> (unit, error) result

Which, from a broad perspective are fine and pretty safe to use.

Now, when I read a bit more through our networking stack, especially the
write path, I'm not so sure anymore about the above signature. The main
question is:

What should a unikernel / networking layer do if the provided buffer is
too small? I.e. are there any reasonable handlers for this?


My proposal would be to retain `into_cstruct`, but also provide a
`into_cstruct_exn` which never returns an error, but raises an exception.

The reasoning behind this: When e.g. the Ethernet layer attempts to send
a packet, and the network interface (responsible for buffer allocation)
allocates a buffer where not even the Ethernet header fits into, what
can the Ethernet layer do? It can retry, hoping that the network
interface will allocate a larger buffer where the Ethernet header fits
(this is rather unlikely, after reading the source code).

There are also some mentions of "minimal MTU" all over the place in
RFCs, which I'd propose to test for in layers "connect" functions, and
fail startup otherwise. This way, the above exceptions will never be
triggered (if the network device behaves in a consistent manner and does
not change its MTU dynamically).

- IPv4: minimal MTU is 68 bytes (+ethernet header)
(https://tools.ietf.org/html/rfc791#page-24)
- IPv6: minimal MTU is 1280 bytes (+ethernet header)
(https://tools.ietf.org/html/rfc2460#section-5)
- ARP requires 28 bytes (+ethernet header)



WDYT?

hannes

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/mirageos-devel