RE: [lwip-devel] tcp_input: order of processing question/comment

[bill]

You're right - a call does need to be after.  All that my receive callback
does *is* output something in response to the data.

This difference isn't huge: ~41.6MbS adding the call before, ~40.3MbS
without the extra call.

Bill

>I guess the intention was to be able to output data enqueued in the
>recv callback. _If_ changing anything, we could add a _second_ call to
>tcp_output _before_ calling the recv callback, but the call _after_ the
>recv callback has to remain there, I think.
> 
> 
> Simon
> 
> 
> bill wrote:
> >
> > Currently In tcp_input, towards the end of the function, the tcp_recv
> > callback is called and if there is no error returned, tcp_output is
> > called to process any pending outgoing data.
> >
> > The questions are: Why would we want an error returned by the receive
> > callback to prevent us from sending any pending data? Wouldn't we
> > still want to send queued ACKs or queued data?
> >
> > The comment is: It would seem to be better to call tcp_output
> > **before** calling the tcp_recv callback. This would allow the other
> > end of the connection to process any data that may be sent in that
> > call while the lwIP side goes off and processes its data in the
> > receive callback. In my bandwidth testing I do see slightly better
> > performance by adding a tcp_output call before the receive callback.
> >
> > Bill
> >
> > ---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > lwip-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/lwip-devel
> >
> 
> 
> 
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-devel