Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)
Hello Jukka,toggle quoted messageShow quoted text
On Wed, 11 Oct 2017 13:06:25 +0300
Jukka Rissanen <firstname.lastname@example.org> wrote:
To clarify, there's no need "to pass information to application" perA solution originally proposed was that the mentioned API functionsWe can certainly implement something like this for the net_context
se. However, the IP stack itself has to know the size of packet headers
at the time of packet creation. IIRC, that was the concern raised for
#119. So, I propose to work towards resolving that issue, and there're
at least 2 approaches:
1. To actually make the stack work like that ("plan ahead"), which might
require some non-trivial refactoring.
2. Or, just conservatively reserve the highest value for the header
size, even if that may mean that some packets will contain less
payload than maximum.
Note that currently we do not have IPv4 fragmentation supportPerhaps. But POSIX "short write" approach would require ~ zero extra
I don't think this comment does good to the usecase presented. OfI would like to raise an additional argument while POSIX-inspiredI would say there is no better or worse approach here. Just a
course, any app is constrained by such, but the algorithm based on POSIX
"short write" approach allows to cover wider usecases in a simpler
Please note that BSD socket API is fully optional and not alwaysAs clarified in the response to Anas, in no way I propose BSD Sockets
API as an alternative to native API. However, I do propose some
design/implementation choices from BSD Sockets API to be adopted for
the native API.
There has not been any public talk in mailing list aboutThat's true, but we can/should think how it may be affected, or we'll
be caught in the cold water with them, and may come up with random
on-spot designs to address such future requirements, instead of
something well thought out.
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog