From: Jakub Kicinski <kuba@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Jonathan Lemon <jonathan.lemon@gmail.com>,
Bjorn Helgaas <helgaas@kernel.org>, Aya Levin <ayal@mellanox.com>,
"David Miller" <davem@davemloft.net>, <saeedm@mellanox.com>,
<mkubecek@suse.cz>, <linux-pci@vger.kernel.org>,
<netdev@vger.kernel.org>, <tariqt@mellanox.com>,
<alexander.h.duyck@linux.intel.com>
Subject: Re: [net-next 10/10] net/mlx5e: Add support for PCI relaxed ordering
Date: Thu, 9 Jul 2020 12:47:26 -0700 [thread overview]
Message-ID: <20200709124726.24315b6e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20200709182011.GQ23676@nvidia.com>
On Thu, 9 Jul 2020 15:20:11 -0300 Jason Gunthorpe wrote:
> > 2) having the driver set RO on the transactions it initiates, which
> > are honored iff the PCI bit is set.
> >
> > It seems that in addition to the PCI core changes, there still is a need
> > for driver controls? Unless the driver always enables RO if it's capable?
>
> I think the PCI spec imagined that when the config space RO bit was
> enabled the PCI device would just start using RO packets, in an
> appropriate and device specific way.
>
> So the fine grained control in #2 is something done extra by some
> devices.
>
> IMHO if the driver knows it is functionally correct with RO then it
> should enable it fully on the device when the config space bit is set.
>
> I'm not sure there is a reason to allow users to finely tune RO, at
> least I haven't heard of cases where RO is a degredation depending on
> workload.
>
> If some platform doesn't work when RO is turned on then it should be
> globally black listed like is already done in some cases.
>
> If the devices has bugs and uses RO wrong, or the driver has bugs and
> is only stable with !RO and Intel, then the driver shouldn't turn it
> on at all.
>
> In all of these cases it is not a user tunable.
>
> Development and testing reasons, like 'is my crash from a RO bug?' to
> tune should be met by the device global setpci, I think.
+1
next prev parent reply other threads:[~2020-07-09 19:47 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 19:52 [pull request][net-next 00/10] mlx5 updates 2020-06-23 Saeed Mahameed
2020-06-23 19:52 ` [net-next 01/10] net/mlx5: Avoid eswitch header inclusion in fs core layer Saeed Mahameed
2020-06-23 21:00 ` Jakub Kicinski
2020-06-23 19:52 ` [net-next 02/10] net/mlx5: FWTrace: Add missing space Saeed Mahameed
2020-06-23 19:52 ` [net-next 03/10] net/mlx5: Add a missing macro undefinition Saeed Mahameed
2020-06-23 19:52 ` [net-next 04/10] net/mlx5: Use kfree(ft->g) in arfs_create_groups() Saeed Mahameed
2020-06-23 19:52 ` [net-next 05/10] net/mlx5e: Remove unused mlx5e_xsk_first_unused_channel Saeed Mahameed
2020-06-23 19:52 ` [net-next 06/10] net/mlx5e: Move including net/arp.h from en_rep.c to rep/neigh.c Saeed Mahameed
2020-06-23 21:02 ` Jakub Kicinski
2020-06-23 19:52 ` [net-next 07/10] net/mlx5e: Move TC-specific function definitions into MLX5_CLS_ACT Saeed Mahameed
2020-06-23 21:03 ` Jakub Kicinski
2020-06-23 21:26 ` Saeed Mahameed
2020-06-23 21:33 ` Jakub Kicinski
2020-06-23 19:52 ` [net-next 08/10] net/mlx5e: vxlan: Use RCU for vxlan table lookup Saeed Mahameed
2020-06-23 19:52 ` [net-next 09/10] net/mlx5e: vxlan: Return bool instead of opaque ptr in port_lookup() Saeed Mahameed
2020-06-23 19:52 ` [net-next 10/10] net/mlx5e: Add support for PCI relaxed ordering Saeed Mahameed
2020-06-23 21:31 ` Jakub Kicinski
2020-06-24 6:56 ` Saeed Mahameed
2020-06-24 7:34 ` Aya Levin
2020-06-24 17:22 ` Jakub Kicinski
2020-06-24 20:15 ` Saeed Mahameed
[not found] ` <20200624133018.5a4d238b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
2020-07-06 13:00 ` Aya Levin
2020-07-06 16:52 ` Jakub Kicinski
2020-07-06 19:49 ` David Miller
2040-07-08 8:22 ` Aya Levin
2020-07-08 23:16 ` Bjorn Helgaas
2020-07-08 23:26 ` Jason Gunthorpe
2020-07-09 17:35 ` Jonathan Lemon
2020-07-09 18:20 ` Jason Gunthorpe
2020-07-09 19:47 ` Jakub Kicinski [this message]
2020-07-10 2:18 ` Saeed Mahameed
2020-07-10 12:21 ` Jason Gunthorpe
2020-07-09 20:33 ` Jonathan Lemon
2020-07-14 10:47 ` Aya Levin
2020-07-23 21:03 ` Alexander Duyck
2020-06-26 20:12 ` Bjorn Helgaas
2020-06-26 20:24 ` David Miller
2020-06-29 9:32 ` Aya Levin
2020-06-29 19:33 ` Bjorn Helgaas
2020-06-29 19:57 ` Raj, Ashok
2020-06-30 7:32 ` Ding Tianhong
2020-07-05 11:15 ` Aya Levin
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=20200709124726.24315b6e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
--to=kuba@kernel.org \
--cc=alexander.h.duyck@linux.intel.com \
--cc=ayal@mellanox.com \
--cc=davem@davemloft.net \
--cc=helgaas@kernel.org \
--cc=jgg@nvidia.com \
--cc=jonathan.lemon@gmail.com \
--cc=linux-pci@vger.kernel.org \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=saeedm@mellanox.com \
--cc=tariqt@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 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).