Hi guys,

It was
posted as https://github.com/zephyrproject-rtos/zephyr/pull/119 . Again,
at that time, there was no consensus about way to solve it, so it was
implemented only for BSD Sockets API.

Much later,
https://github.com/zephyrproject-rtos/zephyr/pull/1330 was posted. It
works in following way: it allows an application to create an
oversized packet

(...)

There're many more
details than presented above, and the devil is definitely in details,
there's no absolutely "right" solution, it's a compromise. I hope that
Jukka and Tomasz, who are proponents of the second (GH-1330) approach
can correct me on the benefits of it.

Actually I missed the fact PR 1330 was about MTU handling. Does not sound generic enough.

In the end I don't approve both of the proposed solution. Let me explain why:

First, let's not rush on this MTU handling just yet, though it is much needed.
We first need this:

-> https://github.com/zephyrproject-rtos/zephyr/issues/3283

it will simplify a lot how packet are allocated. I haven't touched MTU stuff since
I did the net_pkt move because of this feature we'll use.

I foresee a lot of possible improvements with this issue resolved: certainly MTU handling, better memory
management than current frag model, but also better response against low memory (we could after all
send asap a tinier than MTU TCP segment if there was only a small amount of memory available,
and continue with the rest etc...).

Tomasz