linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hyong-Youb Kim <hkim@cspi.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: "Andy Walls" <awalls@md.metrocast.net>,
	"Hyong-Youb Kim" <hykim@myri.com>,
	netdev@vger.kernel.org, "Andy Lutomirski" <luto@amacapital.net>,
	"Toshi Kani" <toshi.kani@hp.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Ingo Molnar" <mingo@kernel.org>,
	linux-kernel@vger.kernel.org,
	"Hal Rosenstock" <hal.rosenstock@gmail.com>,
	"Sean Hefty" <sean.hefty@intel.com>,
	"Suresh Siddha" <sbsiddha@gmail.com>,
	"Rickard Strandqvist" <rickard_strandqvist@spectrumdigital.se>,
	"Mike Marciniszyn" <mike.marciniszyn@intel.com>,
	"Roland Dreier" <roland@purestorage.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Mauro Carvalho Chehab" <mchehab@osg.samsung.com>,
	"Borislav Petkov" <bp@suse.de>, "Mel Gorman" <mgorman@suse.de>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Davidlohr Bueso" <dbueso@suse.de>,
	dave.hansen@linux.intel.com, plagnioj@jcrosoft.com,
	tglx@linutronix.de, "Ville Syrjälä" <syrjala@sci.fi>,
	linux-fbdev@vger.kernel.org, linux-media@vger.kernel.org,
	x86@kernel.org
Subject: Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR
Date: Thu, 16 Apr 2015 13:18:37 +0900	[thread overview]
Message-ID: <20150416041837.GA5712@hykim-PC> (raw)
In-Reply-To: <20150415235816.GG5622@wotan.suse.de>

On Thu, Apr 16, 2015 at 01:58:16AM +0200, Luis R. Rodriguez wrote:
> 
> An alternative... is to just ioremap_wc() the entire region, including
> MMIO registers for these old devices. I see one ethernet driver that does
> this, myri10ge, and am curious how and why they ended up deciding this
> and if they have run into any issues. I wonder if this is a reasonable
> comrpomise for these 2 remaining corner cases.
> 

For myri10ge, it a performance thing.  Descriptor rings are in NIC
memory BAR0, not in host memory.  Say, to send a packet, the driver
writes the send descriptor to the ioremap'd NIC memory.  It is a
multi-word descriptor.  So, to send it as one PCIE MWr transaction,
the driver maps the whole BAR0 as WC and does "copy descriptor; wmb".

Without WC, descriptors would end up as multiple 4B or 8B MWr packets
to the NIC, which has a pretty big performance impact on this
particular NIC.

Most registers that do not want WC are actually in BAR2, which is not
mapped as WC.  For registers that are in BAR0, we do "write to the
register; wmb".  If we want to wait till the NIC has seen the write,
we do "write; wmb; read".

This approach has worked for this device for many years.  I cannot say
whether it works for other devices, though.

  parent reply	other threads:[~2015-04-16  4:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20150410171750.GA5622@wotan.suse.de>
     [not found] ` <CALCETrUG=RiG8S9Gpiqm_0CxvxurxLTNKyuyPoFNX46EAauA+g@mail.gmail.com>
     [not found]   ` <CAB=NE6XgNgu7i2OiDxFVJLWiEjbjBY17-dV7L3yi2+yzgMhEbw@mail.gmail.com>
     [not found]     ` <1428695379.6646.69.camel@misato.fc.hp.com>
     [not found]       ` <20150410210538.GB5622@wotan.suse.de>
     [not found]         ` <1428699490.21794.5.camel@misato.fc.hp.com>
     [not found]           ` <CALCETrUP688aNjckygqO=AXXrNYvLQX6F0=b5fjmsCqqZU78+Q@mail.gmail.com>
     [not found]             ` <20150411012938.GC5622@wotan.suse.de>
     [not found]               ` <CALCETrXd19C6pARde3pv-4pt-i52APtw5xs20itwROPq9VmCfg@mail.gmail.com>
2015-04-13 17:49                 ` ioremap_uc() followed by set_memory_wc() - burrying MTRR Luis R. Rodriguez
2015-04-15 22:38                   ` Andy Walls
2015-04-15 23:42                     ` Andy Lutomirski
2015-04-15 23:59                       ` Andy Walls
2015-04-16  0:58                         ` Andy Lutomirski
2015-04-16  1:01                           ` Andy Walls
2015-04-16 19:19                             ` Andy Lutomirski
2015-04-21 17:35                           ` Luis R. Rodriguez
2015-04-15 23:58                     ` Luis R. Rodriguez
2015-04-16  1:07                       ` Andy Walls
2015-04-21 22:02                         ` Luis R. Rodriguez
2015-04-21 22:08                           ` Luis R. Rodriguez
2015-04-21 22:09                             ` Andy Lutomirski
     [not found]                               ` <5536d47a.95968c0a.1d12.ffffbf85@mx.google.com>
2015-04-21 23:14                                 ` Luis R. Rodriguez
2015-04-16  4:18                       ` Hyong-Youb Kim [this message]
2015-04-16 18:54                         ` Luis R. Rodriguez
2015-04-17  8:00                           ` Hyong-Youb Kim
2015-04-15 20:42 Andy Lutomirski
2015-04-15 20:56 ` H. Peter Anvin
2015-04-15 22:15 ` Luis R. Rodriguez
2015-04-15 22:50 ` Andy Walls
2015-04-15 23:52   ` Andy Lutomirski
2015-04-16  0:33     ` Andy Walls
2015-04-21 22:46 ` Luis R. Rodriguez
2015-04-21 22:57   ` Jason Gunthorpe
2015-04-21 23:39     ` Luis R. Rodriguez
2015-04-22  5:39       ` Jason Gunthorpe
2015-04-22 15:23         ` Luis R. Rodriguez
2015-04-22 15:54           ` Luis R. Rodriguez
2015-04-22 15:59             ` Luis R. Rodriguez
2015-04-22 16:17           ` Jason Gunthorpe
2015-04-22 16:51             ` Luis R. Rodriguez
2015-04-22 18:53             ` Doug Ledford
2015-04-22 19:05               ` Luis R. Rodriguez
2015-04-22 19:10                 ` Doug Ledford
2015-04-22 19:14                   ` Luis R. Rodriguez
2015-04-22 20:46               ` Jason Gunthorpe
2015-04-22 20:58                 ` Doug Ledford
2015-04-22 16:53           ` Andy Lutomirski
2015-04-22 17:07             ` Luis R. Rodriguez

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=20150416041837.GA5712@hykim-PC \
    --to=hkim@cspi.com \
    --cc=awalls@md.metrocast.net \
    --cc=bp@suse.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dbueso@suse.de \
    --cc=hal.rosenstock@gmail.com \
    --cc=hpa@zytor.com \
    --cc=hykim@myri.com \
    --cc=jgross@suse.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mcgrof@suse.com \
    --cc=mchehab@osg.samsung.com \
    --cc=mgorman@suse.de \
    --cc=mike.marciniszyn@intel.com \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=plagnioj@jcrosoft.com \
    --cc=rickard_strandqvist@spectrumdigital.se \
    --cc=roland@purestorage.com \
    --cc=sbsiddha@gmail.com \
    --cc=sean.hefty@intel.com \
    --cc=syrjala@sci.fi \
    --cc=tglx@linutronix.de \
    --cc=toshi.kani@hp.com \
    --cc=vbabka@suse.cz \
    --cc=x86@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;
as well as URLs for NNTP newsgroup(s).