All of lore.kernel.org
 help / color / mirror / Atom feed
From: Moshe Lazer <moshel@dev.mellanox.co.il>
To: davem@davemloft.net
Cc: Or Gerlitz <ogerlitz@mellanox.com>,
	Jack Morgenstein <jackm@dev.mellanox.co.il>,
	Tal Alon <talal@mellanox.com>,
	Yevgeny Petrilin <yevgenyp@mellanox.com>,
	netdev@vger.kernel.org, Amir Vadai <amirv@mellanox.com>
Subject: Re: FW: [PATCH V1 net-next 1/2] pgtable: Add API to query if write combining is available
Date: Wed, 08 Oct 2014 11:44:57 +0300	[thread overview]
Message-ID: <5434F989.2040101@dev.mellanox.co.il> (raw)
In-Reply-To: <925ad10b2ec44e228e69bf0cbe6c0a0e@AMSPR05MB002.eurprd05.prod.outlook.com>


> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, October 07, 2014 10:44 PM
> To: Or Gerlitz
> Cc: netdev@vger.kernel.org; Amir Vadai; jackm@dev.mellanox.co.il; Moshe Lazer; Tal Alon; Yevgeny Petrilin
> Subject: Re: [PATCH V1 net-next 1/2] pgtable: Add API to query if write combining is available
>
> From: Or Gerlitz <ogerlitz@mellanox.com>
> Date: Sun,  5 Oct 2014 11:22:21 +0300
>
>> From: Moshe Lazer <moshel@mellanox.com>
>>
>> Currently the kernel write-combining interface provides a best effort
>> mechanism in which the caller simply invokes pgprot_writecombine().
>>
>> If write combining is available, the region is mapped for it,
>> otherwise the region is (silently) mapped as non-cached.
>>
>> In some cases, however, the calling driver must know if write
>> combining is available, so a silent best effort mechanism is not sufficient.
>>
>> Add writecombine_available(), which returns true if the system
>> supports write combining and false if it doesn't.
>>
>> Signed-off-by: Moshe Lazer <moshel@mellanox.com>
>> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
>> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> This needs some ACKs from MM developers.
>
> But also the situation is more complicated than a simple boolean test.
>
> On some platforms you have to test first whether the range you are trying to write combine can legally be marked in that way.  The DRM layer has all of these per-arch tests to do this properly.
>
> #if defined(__i386__) || defined(__x86_64__)
> 	if (map->type == _DRM_REGISTERS && !(map->flags & _DRM_WRITE_COMBINING))
> 		tmp = pgprot_noncached(tmp);
> 	else
> 		tmp = pgprot_writecombine(tmp);
> #elif defined(__powerpc__)
> 	pgprot_val(tmp) |= _PAGE_NO_CACHE;
> 	if (map->type == _DRM_REGISTERS)
> 		pgprot_val(tmp) |= _PAGE_GUARDED;
> #elif defined(__ia64__)
> 	if (efi_range_is_wc(vma->vm_start, vma->vm_end -
> 				    vma->vm_start))
> 		tmp = pgprot_writecombine(tmp);
> 	else
> 		tmp = pgprot_noncached(tmp);
> #elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
> 	tmp = pgprot_noncached(tmp);
> #endif
The idea was to provide an indication as for whether the arch supports 
write-combining in general.
If we want to benefit from blue flame operations, we need to map the 
blue flame registers as write combining - otherwise there is no benefit. 
So we would like to know if write combining is supported by the system 
or not.

  parent reply	other threads:[~2014-10-08  8:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-05  8:22 [PATCH V1 net-next 0/2] Add pgtable API to query if write combining is available Or Gerlitz
2014-10-05  8:22 ` [PATCH V1 net-next 1/2] pgtable: Add " Or Gerlitz
2014-10-07 19:44   ` David Miller
     [not found]     ` <925ad10b2ec44e228e69bf0cbe6c0a0e@AMSPR05MB002.eurprd05.prod.outlook.com>
2014-10-08  8:44       ` Moshe Lazer [this message]
2014-10-08  8:50         ` FW: " David Laight
2014-10-08 16:24         ` David Miller
2014-10-12  9:54           ` Moshe Lazer
2014-10-26 15:00             ` Moshe Lazer
2014-11-27  6:48             ` Or Gerlitz
2014-12-12 20:36               ` David Miller
2014-10-05  8:22 ` [PATCH V1 net-next 2/2] net/mlx4_core: Disable BF when write combining is not available Or Gerlitz

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=5434F989.2040101@dev.mellanox.co.il \
    --to=moshel@dev.mellanox.co.il \
    --cc=amirv@mellanox.com \
    --cc=davem@davemloft.net \
    --cc=jackm@dev.mellanox.co.il \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@mellanox.com \
    --cc=talal@mellanox.com \
    --cc=yevgenyp@mellanox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.