All of lore.kernel.org
 help / color / mirror / Atom feed
From: Moshe Lazer <moshel@dev.mellanox.co.il>
To: David Miller <davem@davemloft.net>
Cc: ogerlitz@mellanox.com, jackm@dev.mellanox.co.il,
	talal@mellanox.com, yevgenyp@mellanox.com,
	netdev@vger.kernel.org, amirv@mellanox.com, moshel@mellanox.com
Subject: Re: [PATCH V1 net-next 1/2] pgtable: Add API to query if write combining is available
Date: Sun, 12 Oct 2014 12:54:44 +0300	[thread overview]
Message-ID: <543A4FE4.7010807@dev.mellanox.co.il> (raw)
In-Reply-To: <20141008.122450.1919301744382855426.davem@davemloft.net>


On 10/8/2014 7:24 PM, David Miller wrote:
> From: Moshe Lazer <moshel@dev.mellanox.co.il>
> Date: Wed, 08 Oct 2014 11:44:57 +0300
>
>>> #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.
>>
> You completely miss my point.  On a given architectuire it might be
> _illegal_ to map certain address ranges as write-combining without
> checks like the ones above that ia64 needs.
>
> Therefore your proposed interface is by definition insufficient.
Thanks David, I'll try to clarify my point.
For me the writecombine_available() is a way to know if the 
pgprot_writecombine() is effective or just cover call to the 
pgprot_noncached().
I want to use the writecombine_available() regardless to the mapping 
address.
For example in mlx4 query_device I want to indicate that blue-flame is 
not supported if  `writecombine_available() ==  false`.
In this case we don't have the mapping address yet.

Later on if an arch has write-combining (writecombine_available() ==  
true) when we try to map the blue-flame registers (in mlx4_ib_mmap):

     vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);

     if (io_remap_pfn_range(vma, vma->vm_start,
         to_mucontext(context)->uar.pfn +
         dev->dev->caps.num_uars,
         PAGE_SIZE, vma->vm_page_prot))
             return -EAGAIN;

I can be sure that pgprot_writecombine() is not a cover for 
pgprot_noncached().
The address checks that you mentioned should be part of 
io_remap_pfn_range, this function should fail if the vma->vm_start is 
not compatible to the vma->vm_page_prot.
Please let me know if I misunderstood something.

  reply	other threads:[~2014-10-12  9:54 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       ` FW: " Moshe Lazer
2014-10-08  8:50         ` David Laight
2014-10-08 16:24         ` David Miller
2014-10-12  9:54           ` Moshe Lazer [this message]
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=543A4FE4.7010807@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=moshel@mellanox.com \
    --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.