Re: [MirageOS-devel] error handling in encode functions

[Jon Crowcroft <Jon.Crowcroft@xxxxxxxxxxxx>]

in my book, part of the s/w contract with a layer below is that it doesn't 
deliver an illegal size frame
(.e. less than definied min or bigger than max)...to the layer above receiving

i realize this may be a challenge for some zero copy stacks
> 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
> 

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