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. -- 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
