> > 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. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
