Re: [lwip-users] out of pbuf's

[address@hidden]

Mark Six wrote:
> I was thinking it is perhaps possible to optimize the oos queue some more:
> If the data in a pbuf isn't much (and the pbuf must be placed on the oos 
> queue), the data can be copied from one pbuf to another, thereby freeing one 
> pbuf.  If the data is much the pbuf are chained together as it is now. 
>
> If the data in the pbuf's isn't much, the penalty for copying is also not 
> much. But there will be a lot more pbuf's free for reception, making the 
> dropping of packets less.
>
> I haven't had much time to take a look of the internals of the lwip-stack, 
> therefore I don't know if it is possible.
>   
The design of lwIP pbufs doesn't really allow this: you don't have 
information about the 'unused' size of pbufs. Of course, for PBUF_POOL 
pbufs, you know the size, but input packets should work with PBUF_RAM 
also: there is no way of knowing whether there is unused space at the 
end of such a pbuf.

But looking at your issue: I think we might need a limit for incoming 
queue pbufs the same way we have it for outgoing pbufs 
(tcp_pcb.queuelen) to be able limit the number of pbufs in ooseq 
independently of the receive window. Other areas already have this limit 
(the netconn receive mbox can be limited - although this might also need 
a configuration option to configure the default size, raw-API tcp does 
not queue).

Simon