<br><br><div class="gmail_quote">On Wed, Jul 2, 2008 at 11:16 AM, Benjamin Herrenschmidt <<a href="mailto:benh@kernel.crashing.org">benh@kernel.crashing.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
><br>
> Actually the meachanism of stopping the queue and starting it is<br>
> already there. But even then due to some sync issue between the poll<br>
> routine and xmit, we were resulted in using the slots of skb which was<br>
> not actually got freed before.<br>
> I agree this could a bug , Since its not is not clear why buffers are<br>
> not getting transferred timely?. But to handle this we should have a<br>
> work around otherwise system may go out of memory. If we go for<br>
> stopping the queue in these scenario also ( Where a unfreed skbs slot<br>
> has been assigned to another ), Then kernel may call tx timeout, And<br>
> reset the driver. In that case handelling this special case here could<br>
> lead us better performance as compared to stopping the queue<br>
> Let me know your comments.<br>
<br>
</div>Well, if we have a bug, we need to fix it. ie, understand how it is that<br>
the existing mechanism to stop the queue doesn't work, and prevent xmit<br>
from overwriting a non-clear transmit slot (possibly displaying an error<br>
to help us track down the bug).<br>
<br>
I'll have to dig a bit, I'll see if I can find some time tomorrow.</blockquote><div><br>The reason could be sync issue between poll and xmit. I would like to have one clarification , Why in the present design no locks has been implemented to protect the queue from simulatenous access ??<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Cheers,<br>
Ben.<br>
<br>
<br>
<br>
</blockquote></div><br>