TCP queue limit does not take into account headers overhead about picotcp HOT 3 CLOSED

Option 1 seems most suitable to me.
Will solve this @ the Leuven site!

from picotcp.

Tried on linux, with Nagle disabled and a python script sending 1 byte of payload per frame.

For each packet we keep memory used with the following:

• struct pico_frame (sizeof = 160 bytes)
• pico_frame.buffer (buffer_len)
• usage counter(4 bytes)
• node from rb tree (sizeof = 40 bytes)

So for 1 byte of payload we 204 extra bytes.
Wouldn't be a good idea to implement some kind of join for these small segments?

from picotcp.

I refactored the following things:

• the receiving of TCP, when receiving a new segment instead of keeping the full frame
  we are selecting only what we need (payload and seq) and drop the rest of the frame.
• the tcp queues have now a field called overhead which, can be configured and it's taken into account
  when calculating the size of the queue.
• when calculating the size of the queues, if it's an input queue we take into account the payload_len and the size of the input segment structure, if it's an output or hold queue we take into account the buffer_len and the size of a the frame structure.

I performed the following tests (on mbed):

• for input I flood the stack with TCP packets of 1 byte payload
  when the queue is filled, we get a zero window back, the board survives.
• for output, I create a socket, I disable Nagle and I send from mbed towards linux
  a flood of packets of 1 byte payload.
  There is a pressure on memory but I could send continuously without any crash.

The only memory killer I see at this point is the nagle algorithm, because if you repeat the output test with
nagle, for each packet will create a new frame and then join them and afterwards enqueue into tcpq_out, which
is a lot of alloc's and free's for nothing.
I will think of a design to optimize this like the other queues.

from picotcp.