All of lore.kernel.org
 help / color / mirror / Atom feed
From: okaya@codeaurora.org
To: Casey Leedom <leedom@chelsio.com>
Cc: netdev@vger.kernel.org, timur@codeaurora.org,
	sulrich@codeaurora.org, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Ganesh GR <ganeshgr@chelsio.com>,
	linux-kernel@vger.kernel.org, Michael Werner <werner@chelsio.com>,
	SWise OGC <swise@opengridcomputing.com>
Subject: Re: [PATCH v4 12/17] net: cxgb4/cxgb4vf: Eliminate duplicate barriers on weakly-ordered archs
Date: Wed, 21 Mar 2018 20:00:58 -0400	[thread overview]
Message-ID: <11820921c76403bca743c382287aee05@codeaurora.org> (raw)
In-Reply-To: <BY2PR1201MB0983417DC5ECAB85834A84DBC8AA0@BY2PR1201MB0983.namprd12.prod.outlook.com>

On 2018-03-21 19:03, Casey Leedom wrote:
> [[ Appologies for the DUPLICATE email.  I forgot to tell my Mail Agent 
> to
>    use Plain Text. -- Casey ]]
> 
>   I feel very uncomfortable with these proposed changes.  Our team is 
> right
> in the middle of trying to tease our way through the various platform
> implementations of writel(), writel_relaxed(), __raw_writel(), etc. in 
> order
> to support x86, PowerPC, ARM, etc. with a single code base.  This is
> complicated by the somewhat ... "fuzzily defined" semantics and varying
> platform implementations of all of these APIs.  (And note that I'm just
> picking writel() as an example.)
> 
>   Additionally, many of the changes aren't even in fast paths and are 
> thus
> unneeded for performance.
> 
>   Please don't make these changes.  We're trying to get this all sussed 
> out.
> 

I was also given the feedback to look at performance critical path only. 
I am in the process of revisiting the patches.

If you can point me to the ones that are important, I can try to limit 
the changes to those only.

If your team wants to do it, I can drop this patch as well.

I think the semantics of write API is clear. What was actually 
implemented is another story.

I can share a few of my findings.

A portable driver needs to do this.

descriptor update in mem
wmb ()
writel_relaxed ()
mmiowb ()

Using __raw_write() is wrong as it can get reordered.

Using wmb()+writel() is also wrong for performance reasons.

If something is unclear, please ask.

> 

WARNING: multiple messages have this Message-ID (diff)
From: okaya@codeaurora.org (okaya at codeaurora.org)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 12/17] net: cxgb4/cxgb4vf: Eliminate duplicate barriers on weakly-ordered archs
Date: Wed, 21 Mar 2018 20:00:58 -0400	[thread overview]
Message-ID: <11820921c76403bca743c382287aee05@codeaurora.org> (raw)
In-Reply-To: <BY2PR1201MB0983417DC5ECAB85834A84DBC8AA0@BY2PR1201MB0983.namprd12.prod.outlook.com>

On 2018-03-21 19:03, Casey Leedom wrote:
> [[ Appologies for the DUPLICATE email.  I forgot to tell my Mail Agent 
> to
>    use Plain Text. -- Casey ]]
> 
>   I feel very uncomfortable with these proposed changes.  Our team is 
> right
> in the middle of trying to tease our way through the various platform
> implementations of writel(), writel_relaxed(), __raw_writel(), etc. in 
> order
> to support x86, PowerPC, ARM, etc. with a single code base.  This is
> complicated by the somewhat ... "fuzzily defined" semantics and varying
> platform implementations of all of these APIs.  (And note that I'm just
> picking writel() as an example.)
> 
>   Additionally, many of the changes aren't even in fast paths and are 
> thus
> unneeded for performance.
> 
>   Please don't make these changes.  We're trying to get this all sussed 
> out.
> 

I was also given the feedback to look at performance critical path only. 
I am in the process of revisiting the patches.

If you can point me to the ones that are important, I can try to limit 
the changes to those only.

If your team wants to do it, I can drop this patch as well.

I think the semantics of write API is clear. What was actually 
implemented is another story.

I can share a few of my findings.

A portable driver needs to do this.

descriptor update in mem
wmb ()
writel_relaxed ()
mmiowb ()

Using __raw_write() is wrong as it can get reordered.

Using wmb()+writel() is also wrong for performance reasons.

If something is unclear, please ask.

> 

  reply	other threads:[~2018-03-22  0:00 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-20  2:42 [PATCH v4 00/17] netdev: Eliminate duplicate barriers on weakly-ordered archs Sinan Kaya
2018-03-20  2:42 ` Sinan Kaya
2018-03-20  2:42 ` [Intel-wired-lan] [PATCH v4 01/17] i40e/i40evf: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [Intel-wired-lan] [PATCH v4 02/17] ixgbe: eliminate " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [Intel-wired-lan] [PATCH v4 03/17] igbvf: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [Intel-wired-lan] [PATCH v4 04/17] igb: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [Intel-wired-lan] [PATCH v4 05/17] ixgbevf: keep writel() closer to wmb() Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [Intel-wired-lan] [PATCH v4 06/17] ixgbevf: eliminate duplicate barriers on weakly-ordered archs Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [Intel-wired-lan] [PATCH v4 07/17] fm10k: Eliminate " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [PATCH v4 08/17] drivers: net: cxgb: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [PATCH v4 09/17] net: qla3xxx: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [PATCH v4 10/17] qlcnic: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [PATCH v4 11/17] bnx2x: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-22 10:10   ` Kalluru, Sudarsana
2018-03-22 10:10     ` Kalluru, Sudarsana
2018-03-20  2:42 ` [PATCH v4 12/17] net: cxgb4/cxgb4vf: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-21 23:03   ` Casey Leedom
2018-03-21 23:03     ` Casey Leedom
2018-03-22  0:00     ` okaya [this message]
2018-03-22  0:00       ` okaya at codeaurora.org
2018-03-20  2:42 ` [PATCH v4 13/17] net: cxgb3: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [PATCH v4 14/17] net: qlge: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [PATCH v4 15/17] bnxt_en: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [PATCH v4 16/17] qed/qede: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-20  2:42 ` [PATCH v4 17/17] net: ena: " Sinan Kaya
2018-03-20  2:42   ` Sinan Kaya
2018-03-25 12:06   ` Belgazal, Netanel
2018-03-25 12:06     ` Belgazal, Netanel
2018-03-25 13:33     ` okaya
2018-03-25 13:33       ` okaya at codeaurora.org
2018-03-21 15:56 ` [PATCH v4 00/17] netdev: " David Miller
2018-03-21 15:56   ` David Miller
2018-03-21 19:06   ` Sinan Kaya
2018-03-21 19:06     ` 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=11820921c76403bca743c382287aee05@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=ganeshgr@chelsio.com \
    --cc=leedom@chelsio.com \
    --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=sulrich@codeaurora.org \
    --cc=swise@opengridcomputing.com \
    --cc=timur@codeaurora.org \
    --cc=werner@chelsio.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.