public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Re: PCI DAC routines for SN
Date: Thu, 25 Apr 2002 01:00:23 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590701905525@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905493@msgid-missing>

   From: Jesse Barnes <jbarnes@sgi.com>
   Date: Wed, 24 Apr 2002 18:01:59 -0700

   I fully understand and agree with that, and I don't propose adding the
   call just for the fun of it.  It's just that most of the time, it's
   easier software-wise to use the 64 bit consistent mappings if your
   device can support it (e.g. generic ia64, ia64/sn).
   
It isn't easier, in fact it's a lot harder.

The DMA api is confusing enough, and you want to add yet another
interface for device driver author Joe Blow to have to learn?

   I don't think the performance impact of those extra cycles would be
   measurable, but I'd be happy to see any numbers you might have to the
   contrary.
   
You already showed me the numbers.

Hardware folks don't make hardware so you can waste cycles, every
one counts.  I guess this is a fundamental disagreement in approach
between you and me.  So let's just agree to disagree.

You have to show me a significant advantage to add a completely new
API to the mix.  It has to be important enough that it is worth making
every driver author learn the new interface.

This basically boils down to the fact that it must do one of two
things:

1) It must make performance phenominally better.

   In the DAC consistent case, it actaully will decrease bus
   utilization slightly, we agree on this.

2) It must make some DMA performance optimization possible which
   currently is not possible at all.

   I do not believe this is the case.  You've tried to argue that
   SAC consistent memory is precious for mappings, and I've tried
   to show you that the consistent part of the mappings used by
   devices won't even show up on the radar.

We are at an impasse' and I really doubt this is going to change.
All you can do by arguing further is just make me type the same
things a few more times, and I'd like to avoid that, I type enough
already. :-)


  parent reply	other threads:[~2002-04-25  1:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-22 22:34 [Linux-ia64] Re: PCI DAC routines for SN David Mosberger
2002-04-22 22:39 ` Jesse Barnes
2002-04-22 23:07 ` David Mosberger
2002-04-22 23:40 ` Jesse Barnes
2002-04-23  1:34 ` Grant Grundler
2002-04-23 21:11 ` Grant Grundler
2002-04-24  4:04 ` David S. Miller
2002-04-24  5:49 ` Jesse Barnes
2002-04-24  5:50 ` David S. Miller
2002-04-24 16:13 ` Grant Grundler
2002-04-24 17:39 ` David S. Miller
2002-04-24 17:40 ` David S. Miller
2002-04-24 19:45 ` Jesse Barnes
2002-04-24 23:13 ` Jesse Barnes
2002-04-24 23:53 ` David S. Miller
2002-04-25  0:08 ` David S. Miller
2002-04-25  0:11 ` Jesse Barnes
2002-04-25  0:17 ` David S. Miller
2002-04-25  0:21 ` Jesse Barnes
2002-04-25  0:36 ` Jesse Barnes
2002-04-25  0:43 ` David S. Miller
2002-04-25  1:00 ` David S. Miller [this message]
2002-04-25  1:01 ` Jesse Barnes
2002-04-25  1:22 ` Jesse Barnes

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=marc-linux-ia64-105590701905525@msgid-missing \
    --to=davem@redhat.com \
    --cc=linux-ia64@vger.kernel.org \
    /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