linux-fbdev.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>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	"Felix Fietkau" <nbd@openwrt.org>,
	"Benjamin Poirier" <bpoirier@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: Fri, 17 Apr 2015 08:00:46 +0000	[thread overview]
Message-ID: <20150417080046.GA4620@hykim-PC> (raw)
In-Reply-To: <20150416185426.GH5622@wotan.suse.de>

On Thu, Apr 16, 2015 at 08:54:26PM +0200, Luis R. Rodriguez wrote:
> > 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.
> 
> How big are the descriptors?

Some are 64B (a batch of eight 8B descriptors).  Some are 16B.

> > 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".
> 
> Interesting, thanks, yeah using this as a work around to the problem sounds
> plausible however it still would require likely making just as many changes to
> the ivtv and ipath driver as to just do a proper split. I do wonder however if
> this sort of work around can be generalized somehow though so that others could
> use, if this sort of thing is going to become prevalent. If so then this would
> serve two purposes: work around for the corner cases of MTRR use on Linux and
> also these sorts of device constraints.

These Myricom devices are very non-standard in my opinion, at least in
the Ethernet world.  Few, if any, other devices depend so much on WC
like these do.  I think almost all devices now have rings in host
memory.  The NIC pulls them via DMA.  No need for WC, and no need to
special case registers...

> In order to determine if this is likely to be generally useful could you elaborate
> a bit more about the detals of the performance issues of not bursting writes
> for the descriptor on this device.

For this particular Myricom device, performance penalty stems from the
use of slow path in the firmware.  They are not about how effectively
we use PCI Express or latency or bandwidth.  Small MWr packets end up
casuing slow path processing via the firmware in this device.

There are HPC low latency NICs that use WC for different reasons.  To
reduce latency as much as possible, some of these copy small packets
to the NIC memory via PIO (BAR0, and so on), instead of DMA.  They
want WC mapping to minimize PCI Express packets/transactions.

I do not know about video adapters and their use for WC.

> Even if that is done a conversion over to this work around seems it may require
> device specific nitpicks. For instance I note in myri10ge_submit_req() for
> small writes you just do a reverse write and do the first set last, then
> finally the last 32 bits are rewritten, I guess to trigger something?

Right.  The device polls the last word to start sending, DMA, etc.

> > This approach has worked for this device for many years.  I cannot say
> > whether it works for other devices, though.
> 
> I think it should but the more interesting question would be exactly
> *why* it was needed for this device, who determined that, and why?

Hopefully, the above text answers some of your questions.

      reply	other threads:[~2015-04-17  8:00 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 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
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
2015-04-16 18:54                         ` Luis R. Rodriguez
2015-04-17  8:00                           ` Hyong-Youb Kim [this message]

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=20150417080046.GA4620@hykim-PC \
    --to=hkim@cspi.com \
    --cc=awalls@md.metrocast.net \
    --cc=bp@suse.de \
    --cc=bpoirier@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=johannes@sipsolutions.net \
    --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=nbd@openwrt.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).