All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Christoph Hellwig' <hch@lst.de>, Leon Romanovsky <leon@kernel.org>
Cc: Doug Ledford <dledford@redhat.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Avihai Horon <avihaih@nvidia.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	Bart Van Assche <bvanassche@acm.org>,
	"Tom Talpey" <tom@talpey.com>,
	Santosh Shilimkar <santosh.shilimkar@oracle.com>,
	Chuck Lever III <chuck.lever@oracle.com>,
	Keith Busch <kbusch@kernel.org>, Honggang LI <honli@redhat.com>,
	Max Gurtovoy <mgurtovoy@nvidia.com>
Subject: RE: [PATCH v2 rdma-next] RDMA/mlx5: Enable Relaxed Ordering by default for kernel ULPs
Date: Wed, 9 Jun 2021 14:10:43 +0000	[thread overview]
Message-ID: <6b370a8fde1e406192d37c748b79ad01@AcuMS.aculab.com> (raw)
In-Reply-To: <20210609125241.GA1347@lst.de>

From: Christoph Hellwig
> Sent: 09 June 2021 13:53
> 
> On Wed, Jun 09, 2021 at 02:05:03PM +0300, Leon Romanovsky wrote:
> > From: Avihai Horon <avihaih@nvidia.com>
> >
> > Relaxed Ordering is a capability that can only benefit users that support
> > it. All kernel ULPs should support Relaxed Ordering, as they are designed
> > to read data only after observing the CQE and use the DMA API correctly.
> >
> > Hence, implicitly enable Relaxed Ordering by default for kernel ULPs.
> >
> > Signed-off-by: Avihai Horon <avihaih@nvidia.com>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> > Changelog:
> > v2:
> >  * Dropped IB/core patch and set RO implicitly in mlx5 exactly like in
> >    eth side of mlx5 driver.
> 
> This looks great in terms of code changes.  But can we please also add a
> patch to document that PCIe relaxed ordering is fine for kernel ULP usage
> somewhere?

Several things need to happen to use relaxed ordering:
1) The pcie target has to be able to use RO for buffer writes
   and non-RO for control writes.
2) The Linux driver has to enable (1).
3) The generic Linux kernel has to 'not mask' RO on all the PCIe
   bridges and root.
4) The hardware memory system has to 'not break' when passes a RO write.

The comments about the DMA API are almost pointless.
They'd only be relevant if the driver has looking for the last
byte of a buffer to change - and then assuming the rest is valid.

This patch looks like a driver patch - so is changing (2) above.

I've seen another patch that (I think) is enabling (3).
Although some X86 cpu are known to be broken (aka 4).

And I still don't know what a ULP is.

I actually know a bit about TLP.
I found (and fixed) a bug in the Altera/Intel fpga logic
where it didn't like receiving two data TLP in response
to a single read TLP.
We've also (now) got logic in the fpga that traces all received
and sent TLP to an internal memory block.
So I can see what the cpus we have actually generate.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  parent reply	other threads:[~2021-06-09 14:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09 11:05 [PATCH v2 rdma-next] RDMA/mlx5: Enable Relaxed Ordering by default for kernel ULPs Leon Romanovsky
2021-06-09 12:52 ` Christoph Hellwig
2021-06-09 13:53   ` Leon Romanovsky
2021-06-09 13:59     ` Christoph Hellwig
2021-06-10  7:44       ` Leon Romanovsky
2021-06-09 14:10   ` David Laight [this message]
2021-06-09 14:37     ` Chuck Lever III
2021-06-09 15:05       ` David Laight
2021-06-09 15:09         ` Jason Gunthorpe
2021-06-09 15:48           ` David Laight
2021-06-21 18:02 ` Jason Gunthorpe
2021-06-21 20:20   ` Christoph Hellwig
2021-06-21 23:18     ` Jason Gunthorpe
2021-06-22  6:20       ` Leon Romanovsky
2021-06-23 23:06 ` Max Gurtovoy
2021-06-24  6:38   ` Leon Romanovsky
2021-06-24  7:39     ` Max Gurtovoy
2021-06-24 11:36       ` Jason Gunthorpe
2021-06-27  7:32         ` Leon Romanovsky
2021-06-27  7:30       ` Leon Romanovsky

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=6b370a8fde1e406192d37c748b79ad01@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=avihaih@nvidia.com \
    --cc=bvanassche@acm.org \
    --cc=chuck.lever@oracle.com \
    --cc=dledford@redhat.com \
    --cc=hch@lst.de \
    --cc=honli@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=kbusch@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mgurtovoy@nvidia.com \
    --cc=santosh.shilimkar@oracle.com \
    --cc=tom@talpey.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.