[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Re: [lwip] Pbuf Pool
|
From: |
James Roth |
|
Subject: |
[lwip-users] Re: [lwip] Pbuf Pool |
|
Date: |
Thu, 09 Jan 2003 01:22:27 -0000 |
--------------060409020005030106050702
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Kieran Mansley wrote:
>On Tue, 9 Apr 2002, James Roth wrote:
>
>>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.]
>
Ok, I was confused (and I still am).
Now I see c8900if_service boiling down to a pbuf_pool_alloc call
where pbuf_pool_free_lock is 1. This is because tcpip_thread boiled
down to a pbuf_refresh call, which set free_lock to 1 and then got
preempted in the for loop where it fishes through pbuf_pool.
A previous mail thread convinced me that this somehow could not
happen, and that these "lock" variables would not need to be protected
by sem's. It looks like 2 threads are using the lock in a non-atomic
way here. Right? pbuf_refresh uses a sem, but pbuf_alloc does not.
Also, i've noticed that if I turn on stats and really hammer the
system with ethernet traffic, the "used" field will sometimes go
negative from a non atomic decrement operation.
--
James Roth
Shugyo Design Technologies
http://www.shugyodesign.com/
--------------060409020005030106050702
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
<body>
Kieran Mansley wrote:<br>
<blockquote type="cite" cite="mid:address@hidden">
<pre wrap="">On Tue, 9 Apr 2002, James Roth wrote:<br></pre>
<blockquote type="cite">
<pre wrap="">I have seen the pool locked in this case (using a
debugger):<br><br> 1. A pbuf_* function is called. It locks the pool.<br>
2. The pbuf_ function indirectly results in a call to sys_sem_*
or<br>similar.<br> 3. The sem function results in a call to a timeout
function.<br> 4. Finally, the timeout function calls a pbuf_* function.
The pool<br>is still locked from step 1.<br></pre>
</blockquote>
<pre wrap=""><!----><br>The pbuf_pool_free_lock and pbuf_pool_alloc_lock
are only used by<br>pbuf_pool_alloc and pbuf_refresh. Neither call a sys_sem_*
or similar<br>while locked, so I don't think this can be right.<br><br>Adam and
I discussed this some time ago. See the thread beginning with<br><a
class="moz-txt-link-freetext"
href="http://www.sics.se/~adam/lwip/maillist/msg00600.html";>http://www.sics.se/~adam/lwip/maillist/msg00600.html</a><br><br>I
implemented the suggestion, but it didn't seem to alleviate the
problem,<br>and it was a bit of a hack so I backed it out. Instead, I've
decided to<br>re-engineer the structure of the stack to avoid the problem, but
this is<br>unlikely to be a change that most people would be interested in as
it'll<br>be fairly major, and specific to my
network.<br><br>Kieran<br><br>[This message was sent through the lwip
discussion list.]<br></pre>
</blockquote>
Ok, I was confused (and I still am). <br>
<br>
Now I see c8900if_service boiling down to a pbuf_pool_alloc
call where
pbuf_pool_free_lock is 1. This is because tcpip_thread boiled down to a
pbuf_refresh call, which set free_lock to 1 and then got preempted in the
for loop where it fishes through pbuf_pool. <br>
<br>
A previous mail thread convinced me that this somehow could
not happen,
and that these "lock" variables would not need to be protected by sem's.
It looks like 2 threads are using the lock in a non-atomic way here.
Right?
pbuf_refresh uses a sem, but pbuf_alloc does not. <br>
<br>
Also, i've noticed that if I turn on stats and really hammer
the system
with ethernet traffic, the "used" field will sometimes go negative from a
non atomic decrement operation.<br>
<br>
<br>
<pre class="moz-signature" cols="$mailwrapcol">--
James Roth
Shugyo Design Technologies
<a class="moz-txt-link-freetext"
href="http://www.shugyodesign.com/";>http://www.shugyodesign.com/</a>
</pre>
<br>
</body>
</html>
--------------060409020005030106050702--
[This message was sent through the lwip discussion list.]