David Miller <da...@davemloft.net> writes: > From: Måns Rullgård <m...@mansr.com> > Date: Wed, 11 Nov 2015 19:25:46 +0000 > >> David Miller <da...@davemloft.net> writes: >> >>> From: Måns Rullgård <m...@mansr.com> >>> Date: Wed, 11 Nov 2015 19:17:07 +0000 >>> >>>> David Miller <da...@davemloft.net> writes: >>>> >>>>> From: Måns Rullgård <m...@mansr.com> >>>>> Date: Wed, 11 Nov 2015 19:09:19 +0000 >>>>> >>>>>> David Miller <da...@davemloft.net> writes: >>>>>> >>>>>>> From: Måns Rullgård <m...@mansr.com> >>>>>>> Date: Wed, 11 Nov 2015 18:25:05 +0000 >>>>>>> >>>>>>>> If the TX DMA channel is idle when start_xmit is called, it can be >>>>>>>> started immediately. Checking the DMA status and starting it if >>>>>>>> idle has to be done atomically somehow. >>>>>>> >>>>>>> ->ndo_start_xmit() is guaranteed to be invoked atomically, protected >>>>>>> by the TX queue spinlock. >>>>>> >>>>>> Yes, but the DMA needs to be restarted from some other context if it was >>>>>> busy when start_xmit checked. >>>>> >>>>> Then you can probably use the TXQ lock in the interrupt handler just for >>>>> that. >>>> >>>> That seems a bit heavy-handed when the critical section for this is only >>>> a tiny part of the start_xmit function. >>> >>> Then what synchornization primitive other than spin locks are you going >>> to use for this? >>> >>> My point is that there is a spinlock the core code is _already_ taking, >>> unconditionally, when ->ndo_start_xmit() executes. And you can therefore >>> take advantage of that rather than using another lock of your own. >> >> I get that. But that remains locked for the duration of ndo_start_xmit() >> whereas the part that needs to be synchronised with the DMA completion >> IRQ handler is tiny. Having the IRQ handler spin for the duration of >> ndo_start_xmit() seemed silly to me. > > I don't think it's silly at all.
I'm sure I read somewhere that the time spent spinning on a lock should be kept as small as possible. > And unless you can measure it making a difference, don't knock the idea. I tried using netif_tx_lock() in the IRQ handler instead, and it locked up solid. Clearly that was the wrong thing to do. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html