public inbox for linux-sh@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Steve Glendinning <steve.glendinning@smsc.com>
Cc: netdev@vger.kernel.org, linux-sh@vger.kernel.org,
	Ian Saturley <ian.saturley@smsc.com>
Subject: Re: [RFC PATCH 1/2] smsc911x: add support for sh3 RX DMA
Date: Mon, 24 Nov 2008 03:42:37 +0000	[thread overview]
Message-ID: <20081124034237.GB26414@linux-sh.org> (raw)
In-Reply-To: <1227456274-10388-1-git-send-email-steve.glendinning@smsc.com>

On Sun, Nov 23, 2008 at 04:04:33PM +0000, Steve Glendinning wrote:
> I've been working on adding DMA support to the smsc911x driver.  As this 
> family of devices is non-pci, DMA transfers must be initiated and 
> controlled by the host CPU.  Unfortunately this makes some of the code 
> necessarily platform-specific.
> 
> This patch adds RX DMA support for the sh architecture.  Tested on 
> SH7709S (sh3), where it gives a small (~10%) iperf tcp throughput 
> increase.  DMA or PIO is selected at compile-time.
> 
> My first attempt stopped NAPI polling during a DMA transfer, then used 
> DMA completion interrupts to pass the packet up and re-enable polling.
> Obviously this defeats the interrupt-mitigation of NAPI, and on my test 
> platform actually *reduced* performance!
> 
> This patch leaves NAPI polling enabled, so a later poll completes the 
> transfer.  I'm concerned this is essentially busy-waiting on the 
> transfer, but it does show a small performance gain.  Is this a good or 
> bad idea?
> 
> I'd be interested to hear if anyone has advice on how to make this 
> patch more generic.  There's definitely been interest from arm pxa
> users in adding DMA, and some of this code must be re-usable for this.
> 
> Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>

The intent was to move everything over to the dmaengine framework and
have drivers (especially generic ones) opt for using that instead. This
hasn't happened yet, but it doesn't seem like there is much point in
adding hacks to the smsc911x driver at present given the overhead
involved in the interrupt handling. While this is something that can
easily be improved, I would rather put more effort in to getting things
moved over to the generic frameworks now that they exist, and optimize
later.

  parent reply	other threads:[~2008-11-24  3:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-23 16:04 [RFC PATCH 1/2] smsc911x: add support for sh3 RX DMA Steve Glendinning
2008-11-23 16:04 ` [RFC PATCH 2/2] smsc911x: add support for sh3 TX DMA Steve Glendinning
2008-11-24  3:42 ` Paul Mundt [this message]
2008-11-24 22:46   ` [RFC PATCH 1/2] smsc911x: add support for sh3 RX DMA David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081124034237.GB26414@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=ian.saturley@smsc.com \
    --cc=linux-sh@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=steve.glendinning@smsc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox