[lwip-devel] [bug #3031] Implement a new fully pool-based pbuf implementation.

[Jonathan Larmour]

Follow-up Comment #19, bug #3031 (project lwip):

Re comment #17: Only raw API applications would be affected. anything using
the socket API or netbuf_* functions of the sequential API would be fine. But
even then, I think it's always been the case that we should have been able to
handle chained PBUF_RAMs, and the issue in tcp_enqueue falls into the
category of a bug, not a feature ;).

Re comment #16 pbuf_clen() versus new pbuf_count. 
Firstly be aware that adding one-byte to struct pbuf would probably in
practice add 4 for most people, due to alignment constraints (assuming 32-bit
ints). 

I think most chains will be short enough that pbuf_clen() isn't much of an
issue - the biggest thing would be the function call overhead itself, and to
be honest, pbuf_clen() is so short it should probably be made a function-like
macro *anyway*.

OTOH, I'm not sure there is anything magic about the queue len. Correct me if
I'm wrong, but it doesn't appear to represent anything other than a contrived
view of "how long the queue is". The value that really represents something
is the number of bytes in the queue. So perhaps is it ok for it to just
_respresent_ the length of the queue, rather than being an accurate count of
the number of pbufs?


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?3031>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/