Re: [lwip-users] tcp_enqueue - Does it slow down lwip?

[Paul C]

Hi

There seems to be a lot of messages in early 2003 on this issue.
The ones to look for are tcp_tuning and tcp_output. The basic
argument is that the stack can be "optimised" for latency by performing
tcp_output() after every tcp_write or throughput by combining all
the tcp_write()s then doing a tcp_output. (However returning ERR_MEM
and doing nothing about it will hurt both cases!)

So I guess that the tcp_enqueue returning ERR_MEM means that the 
user code has to perform a tcp_output() as part of the error recovery.
I'll have to check if any other places return ERR_MEM where tcp_output()
would not be allowable. 

Comments?

Paul


On Wed, 15 Dec 2004 10:00:48 +0000, "Kieran Mansley" <address@hidden>
said:
> On Wed, 2004-12-15 at 19:47 +1030, Paul C wrote:
> > Hi 
> > 
> > I have had a bit more of a dig around the tcp_enqueue() issue. 
> > My current work around is in tcp_write, check the return 
> > value of tcp_enqueue() if it returns ERR_MEM do a tcp_output and
> > retry tcp_enqueue. I think this is beneficial as once
> > the queue length is maxed no more can be written so the pcb, so the pcb
> > would be stuck until the tcp_tmr tried to send it. It has to be better
> > to send it on its way ASAP!
> 
> The fact that tcp_write() does not call tcp_output() has been discussed
> before, althought I don't remember all the details.  Might be worth
> checking the mailing list archive.  I think the outcome was we decided
> to document this fact, rather than change the implementation, so there
> must have been some negative effect of this action too.  Perhaps
> restricting it to only when tcp_enqueue() returns ERR_MEM is a good
> compromise though.  
> 
> Kieran
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users