On Wed, Jul 2, 2008 at 11:16 AM, Benjamin Herrenschmidt < [EMAIL PROTECTED]> wrote:
> > > > > Actually the meachanism of stopping the queue and starting it is > > already there. But even then due to some sync issue between the poll > > routine and xmit, we were resulted in using the slots of skb which was > > not actually got freed before. > > I agree this could a bug , Since its not is not clear why buffers are > > not getting transferred timely?. But to handle this we should have a > > work around otherwise system may go out of memory. If we go for > > stopping the queue in these scenario also ( Where a unfreed skbs slot > > has been assigned to another ), Then kernel may call tx timeout, And > > reset the driver. In that case handelling this special case here could > > lead us better performance as compared to stopping the queue > > Let me know your comments. > > Well, if we have a bug, we need to fix it. ie, understand how it is that > the existing mechanism to stop the queue doesn't work, and prevent xmit > from overwriting a non-clear transmit slot (possibly displaying an error > to help us track down the bug). > > I'll have to dig a bit, I'll see if I can find some time tomorrow. 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 ?? > > > Cheers, > Ben. > > > >
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
