lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Re: [lwip] questions & suggestions


From: Adam Dunkels
Subject: [lwip-users] Re: [lwip] questions & suggestions
Date: Wed, 08 Jan 2003 23:06:42 -0000

Hi Adel!

On Wednesday 12 December 2001 12.50, you wrote:
> I have looked through your 0.5 code and it seems that the pbuf management
> is OK. But I think there can be made a small improvement:
> You call pbuf_refresh() in pbuf_realloc() and in pbuf_free() and in any
> case if the pbuf_pool is busy now (because of the others threads ONLY) the
> corresponding thread will be blocked. I think that it is not very good.
> Your suggestion to add a separate timeout-based thread to move buffers from
> the pbuf_pool_free_cache to the pbuf_pool list looks attractive very much.
> What if you leave pbuf_refresh() function (to refresh pbuf_pool by fact of
> appearing a free buffer in pbuf_pool_free_cache) and also add a low
> priority timeout-based thread to do the same job. In this case the
> pbuf_refresh() function should not block the corresponding thread but just
> try the semaphore: if it is locked - refreshing is not made and will be
> actually made later by  timeout-based thread dedicated for this purpose. I
> believe that using this approach you can increase the TCP/IP stack's
> overall performance.

Your suggestion is a good one, but there are a few problems with it as well. 
First, the sys_arch does not define any function for just trying a semaphore, 
which means that the sys_arch would have to be updated again. Second, I don't 
think that either pbuf_free() or pbuf_refresh() will block that often. The 
semaphore is just a mutex for quite a small area of code (two lines for 
deallocation, a few more for refreshing) and the semaphore will only block if 
there is another thread in that area. I don't think that the chance of that 
is too large. But it depends on the usage/application/environment.

Also, if buffers aren't moved from pbuf_pool_free_cache to pbuf_pool fast 
enough, incoming packets will start getting dropped.

Still, having a periodic low-priority thread which does pbuf_refresh() 
probably is a good idea in any case.

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]