mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Chopra, Manish" <Manish.Chopra@cavium.com>
To: Sinan Kaya <okaya@codeaurora.org>, David Miller <davem@davemloft.net>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"timur@codeaurora.org" <timur@codeaurora.org>,
	"sulrich@codeaurora.org" <sulrich@codeaurora.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Elior, Ariel" <Ariel.Elior@cavium.com>,
	Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v5 3/5] bnx2x: Eliminate duplicate barriers on weakly-ordered archs
Date: Sat, 24 Mar 2018 14:30:17 +0000	[thread overview]
Message-ID: <DM2PR07MB685FD0A0877865A41EE723889AF0@DM2PR07MB685.namprd07.prod.outlook.com> (raw)
In-Reply-To: <b4553d26-b326-15be-dcac-12594ea7c5b5@codeaurora.org>

> -----Original Message-----
> From: Sinan Kaya [mailto:okaya@codeaurora.org]
> Sent: Friday, March 23, 2018 10:44 PM
> To: David Miller <davem@davemloft.net>
> Cc: netdev@vger.kernel.org; timur@codeaurora.org; sulrich@codeaurora.org;
> linux-arm-msm@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Elior,
> Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2 <Dept-
> EngEverestLinuxL2@cavium.com>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v5 3/5] bnx2x: Eliminate duplicate barriers on weakly-
> ordered archs
> 
> On 3/23/2018 1:04 PM, David Miller wrote:
> > From: Sinan Kaya <okaya@codeaurora.org>
> > Date: Fri, 23 Mar 2018 12:51:47 -0400
> >
> >> It could if txdata->tx_db was not a union. There is a data dependency
> >> between txdata->tx_db.data.prod and txdata->tx_db.raw.
> >>
> >> So, no reordering.
> >
> > I don't see it that way, the code requires that:
> >
> >  	txdata->tx_db.data.prod += nbd;
> >
> > is visible before the doorbell update.>
> > barrier() doesn't provide that.
> >
> > Neither does writel_relaxed().  However plain writel() does.
> 
> Correct for some architectures including ARM but not correct universally.
> 
> writel() just guarantees register read/writes before and after to be ordered
> when HW observes it.
> 
> writel() doesn't guarantee that the memory update is visible to the HW on all
> architectures.
> 
> If you need memory update visibility, that barrier() should have been a
> wmb()
> 
> A correct multi-arch pattern is
> 
> wmb()
> writel_relaxed()
> mmiowb()
> 

Sinan,  Since you have mentioned the use of mmiowb() here after writel_relaxed().
I believe this is not always correct for all types of IO mapped memory [Specially if IO memory is mapped using write combined (for ex. Ioremap_wc())].
We have a current issue on our NIC (qede) driver on x86 for which the patch is already been sent more than a week ago [Still awaiting to hear from David on that].
where mmiowb() seems to be useless since we use write combined mapped doorbell and mmiowb() just seems to be a compiler barrier() there.
So in order to flush write combined buffer we really need writel_relaxed() followed by a wmb() to synchronize writes among CPU cores.
I think  the correct pattern in such cases (for write combined IO) would have been like below - 

wmb();
writel_relaxed();
wmb(); -> To flush the writes actually.

Thanks.

  parent reply	other threads:[~2018-03-24 14:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1521738603-23596-1-git-send-email-okaya@codeaurora.org>
2018-03-22 17:09 ` [PATCH v5 1/5] net: qla3xxx: " Sinan Kaya
2018-03-22 17:09 ` [PATCH v5 2/5] qlcnic: " Sinan Kaya
2018-03-22 17:10 ` [PATCH v5 3/5] bnx2x: " Sinan Kaya
2018-03-23 16:20   ` David Miller
2018-03-23 16:31     ` Sinan Kaya
2018-03-23 16:43       ` David Miller
2018-03-23 16:51         ` Sinan Kaya
2018-03-23 17:04           ` David Miller
2018-03-23 17:13             ` Sinan Kaya
2018-03-23 17:16               ` David Miller
2018-03-24 14:30               ` Chopra, Manish [this message]
2018-03-24 14:57                 ` Sinan Kaya
2018-03-22 17:10 ` [PATCH v5 4/5] net: qlge: " Sinan Kaya
2018-03-22 17:10 ` [PATCH v5 5/5] bnxt_en: " Sinan Kaya

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=DM2PR07MB685FD0A0877865A41EE723889AF0@DM2PR07MB685.namprd07.prod.outlook.com \
    --to=manish.chopra@cavium.com \
    --cc=Ariel.Elior@cavium.com \
    --cc=Dept-EngEverestLinuxL2@cavium.com \
    --cc=davem@davemloft.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=okaya@codeaurora.org \
    --cc=sulrich@codeaurora.org \
    --cc=timur@codeaurora.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

all inboxes | Powered by JetHome®