[lwip-devel] [patch #6330] Limit input packets on tcpip mbox

[Simon Goldschmidt]

Follow-up Comment #7, patch #6330 (project lwip):

> BTW you would also need to remove the "MySleep" call from that patch.

oops... that was the only way I could receive frames faster than tcpip_thread
can process them under windows :)

> something like #ifndef TCPIP_MAX_INPKTS_QUEUED around every addition in the
patch?

The #ifndef should be around the definition of the 3 defines (max packets,
refused/allowed macro.

> The application can send, but if TCP ACKs can't get returned, what's the
point.

Of course that's true for TCP connections. In a scenario where sending UDP
frames out is the most important thing (it _is_ for us...), you sometimes
don't mind a few dropped input packets.

Anyway many of the currently used small embedded systems are not capable to
process 100 mbit at full wire-speed, so you will always drop some packets when
e.g. a PC sends at full wire-speed. The only question is what to do in that
situation!

I don't have a real problem with this not going in (I always can add it to my
local copy only), I just think sys_mbox_trypost might not be enough: what
would you suggest for tcpip_callback, for example? Block or don't block? If
the queue can be full, tcpip_callback would be unsafe to call from interrupt
context!

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?6330>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/