From: David Miller <davem@davemloft.net>
To: eli@dev.mellanox.co.il
Cc: roland@purestorage.com, netdev@vger.kernel.org
Subject: Re: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers
Date: Mon, 07 Mar 2011 13:50:59 -0800 (PST) [thread overview]
Message-ID: <20110307.135059.229761671.davem@davemloft.net> (raw)
In-Reply-To: <20110307.134931.232736253.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 07 Mar 2011 13:49:31 -0800 (PST)
> From: Eli Cohen <eli@dev.mellanox.co.il>
> Date: Mon, 7 Mar 2011 23:48:12 +0200
>
>> On Mon, Mar 07, 2011 at 01:40:01PM -0800, David Miller wrote:
>>> From: Eli Cohen <eli@dev.mellanox.co.il>
>>> Date: Mon, 7 Mar 2011 23:36:48 +0200
>>>
>>> > Specifically, some archs may not support write combining.
>>>
>>> They should just create a non-write-combining mapping if they
>>> don't support it.
>>>
>>
>> I wouldn't expect that since the caller function could be mislead to
>> believe it has a write combining capable area.
>
> It's a performance optimization, if you don't get write combining you'll
> get more strict ordering, rather than less.
>
> It cannot cause problem.
BTW, if we did as you suggest, fail if we don't support write combining,
then half the drivers in the tree would fail to probe on sparc64.
Every other driver expects it to succeed, with either write-combining
or more strict ordering semantics. Never to fail simply because
write-combining isn't supported.
It's a request, not a requirement.
next prev parent reply other threads:[~2011-03-07 21:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CFE9BFE80FFE4D4892AA5D31387E310F02F3ED@mtldag01.mtl.com>
2011-03-07 21:36 ` FW: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers Eli Cohen
2011-03-07 21:40 ` David Miller
2011-03-07 21:48 ` Eli Cohen
2011-03-07 21:49 ` David Miller
2011-03-07 21:50 ` David Miller [this message]
2011-03-07 21:58 ` Eli Cohen
2011-03-07 22:09 ` David Miller
2011-03-07 10:17 Yevgeny Petrilin
2011-03-07 21:07 ` Roland Dreier
2011-03-07 21:27 ` 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=20110307.135059.229761671.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=eli@dev.mellanox.co.il \
--cc=netdev@vger.kernel.org \
--cc=roland@purestorage.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;
as well as URLs for NNTP newsgroup(s).