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. :-)
next prev 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