lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] Re: [lwip] Pbuf Pool


From: Mumtaz Ahmad
Subject: [lwip-users] Re: [lwip] Pbuf Pool
Date: Thu, 09 Jan 2003 01:47:51 -0000

Hi
I used the mechanism in which i reattempt after a small sleep (around 2
milli sec) . The sleep command gives time to the thread thats has locked the
pool and on next task switch the attempting thread succeeds in getting a
pbuf .

----- Original Message -----
From: Kieran Mansley <address@hidden>
To: <address@hidden>
Sent: Wednesday, April 10, 2002 1:49 PM
Subject: Re: [lwip] Pbuf Pool


> On Tue, 9 Apr 2002, James Roth wrote:
> > Mumtaz Ahmad wrote:
> >
> > >Hi
> > >
> > >I am using lwip on trimedia board . I am facing a problem when the
ethernet
> > >interface transfers a buffer to lwip .I am experiencing a data loss as
> > >POOL_BUFFS are not available all the time . I have tried to change the
> > >number of POOL Buffers but with no success . Most failures are due to
free
> > >lock problem. I tried to understand it but somehow i ahave been unable
to
> > >understand all this caching mechanism and i donot know why i get pbuff
pool
> > >locked often . Any suggestion in this regard ?
> > >
>
> > I have seen the pool locked in this case (using a debugger):
> >
> >     1.  A pbuf_* function is called.  It locks the pool.
> >     2.  The pbuf_ function indirectly results in a call to sys_sem_* or
> > similar.
> >     3.  The sem function results in a call to a timeout function.
> >     4.  Finally, the timeout function calls a pbuf_* function.  The pool
> > is still locked from step 1.
>
> The pbuf_pool_free_lock and pbuf_pool_alloc_lock are only used by
> pbuf_pool_alloc and pbuf_refresh.  Neither call a sys_sem_* or similar
> while locked, so I don't think this can be right.
>
> Adam and I discussed this some time ago.  See the thread beginning with
> http://www.sics.se/~adam/lwip/maillist/msg00600.html
>
> I implemented the suggestion, but it didn't seem to alleviate the problem,
> and it was a bit of a hack so I backed it out.  Instead, I've decided to
> re-engineer the structure of the stack to avoid the problem, but this is
> unlikely to be a change that most people would be interested in as it'll
> be fairly major, and specific to my network.
>
> Kieran
>
> [This message was sent through the lwip discussion list.]

[This message was sent through the lwip discussion list.]




reply via email to

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