Re: [lwip-users] LWIP UDP throughput with Iperf

[Sergio R. Caprile]

Data size can't be 2MB/s, by data size I mean the size of the data 
chunks you are handling in each frame, you expect to handle an amount of 
data in a period of time, and that data is handled in pieces, if pieces 
are too short you need to handle many pieces, if pieces are too long, 
you need more room to handle them. Those pieces are of xxx bytes, where 
xxx = ? You should probably get more performance out of longer pieces.
Those pieces are staying somewhere before they are sent back. There is 
no reason for them to stay "inside lwIP" unless you are not getting them 
out in due time.
Are they being queued on receive ?
Are they being queued on transmit ?
Is your application called fast enough by your OS ?
Is the interface serviced fast enough by your OS ?
Are priorities getting things worse ?
I would start by measuring the number of frames in a certain time, and 
seeing why they are queuing somewhere; how much time they spend in each 
stage (in rx queue, in your application, in tx queue). That may need you 
to add instrumentation to the piece of code where frames are received 
and sent by lwIP, and of course by your application.
As stated before:
> > The amount of memory used depends on your application. There is no
> > reason to queue UDP datagrams unless you don't get them as they come.
And avise again:
> > If you are expecting high-performance, you should be using RAW API, and
> > so each received frame carrying a UDP datagram would trigger a callback
> > to your application receive function.