Messages in this thread | | | Date | Sat, 16 Oct 1999 00:32:28 +0200 | From | Henner Eisen <> | Subject | Re: Stalls on sync PPP transmission (new card) |
| |
>>>>> "Ivan" == Ivan Passos <ivan@mediacity.com> writes: >> >> Leave it out. tbusy should only be set in the >> dev->hard_start_xmit() thread when an xmitter-busy condition is >> detected (in your driver, this is probably at those location >> where your cpc_queue_xmit() returns 1). Other threads >> (e.g. interrupt handlers) are only allowed to clear tbusy.
Ivan> This is _not_ the interrupt handler, this is the function to Ivan> which >dev-> hard_start_xmit() points to. Furthermore, isn't the
Yes, I was aware of this.
>dev-> test_and_set_bit This particular atomic bitop was used before linux 1.2.9 to serialize dev->hard_start_xmit() calls internally. This is no longer necessary because since linux 1.2.9, the network layer takes care that for each net device, dev->hard_start_xmit is called in a single threaded manner.
Ivan> _BUT_ for this device, as it has _large_ DMA buffers (you Ivan> can queue up to 32KB of TX data per channel), the driver Ivan> doesn't need to wait until the board has actually physically Ivan> placed the data in the line to tell the upper layer that Ivan> it's ready to receive more data. Once the data from the Ivan> upper layer is in the DMA buffer, the driver is ready to Ivan> receive more data from the upper layer. That's why tbusy is Ivan> _set_ and _cleared_ in the same function (cpc_queue_xmit, Ivan> which is dev->hard_start_xmit).
But the linux network layer will easily fill up the whole 32KB DMA buffer, if this is full, your deviceŽs hard_start_xmit will return with tbusy set, and after that the network layer will cease to call dev->hard_start_xmit(). With tbusy set, the hardware will send out the frames in the DMA buffer, makeing space for new frames, but as tbusy remains set, the upper layer wonŽt call dev->hard_start_xmit() again. (well, after some time it will although tbusy is set, this is exactly to trigger the xmit timeout recovery in your xmit function).
BTW, even if your hardware can queue 32kB, it might be better for performance to limit the length ob the internal buffer. It is better to let the upper layer take care of queuing because the upper layer can be more intelligent (fair queueung, prioritizing,...).
Henner
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |