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. And unless you can measure it making a difference, don't knock the idea. -- 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
