[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lwip-devel] tcp_input: order of processing question/comment
From: |
bill |
Subject: |
RE: [lwip-devel] tcp_input: order of processing question/comment |
Date: |
Wed, 4 Feb 2009 14:12:49 -0500 |
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