Messages in this thread | | | Date | Wed, 11 Nov 2015 14:26:50 -0500 (EST) | Subject | Re: [PATCH v5] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller | From | David Miller <> |
| |
From: Måns Rullgård <mans@mansr.com> Date: Wed, 11 Nov 2015 19:25:46 +0000
> David Miller <davem@davemloft.net> writes: > >> From: Måns Rullgård <mans@mansr.com> >> Date: Wed, 11 Nov 2015 19:17:07 +0000 >> >>> David Miller <davem@davemloft.net> writes: >>> >>>> From: Måns Rullgård <mans@mansr.com> >>>> Date: Wed, 11 Nov 2015 19:09:19 +0000 >>>> >>>>> David Miller <davem@davemloft.net> writes: >>>>> >>>>>> From: Måns Rullgård <mans@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.
| |