On Tue, Apr 06, 2021 at 08:58:54AM +0300, Leon Romanovsky wrote:
> On Tue, Apr 06, 2021 at 07:27:17AM +0200, Christoph Hellwig wrote:
> > On Tue, Apr 06, 2021 at 08:23:28AM +0300, Leon Romanovsky wrote:
> > > The same proposal (enable unconditionally) was raised during
> > > submission preparations and we decided to follow same pattern
> > > as other verbs objects which receive flag parameter.
> >
> > A flags argument can be added when it actually is needed. Using it
> > to pass an argument enabled by all ULPs just gets us back to the bad
> > old days of complete crap APIs someone drew up on a whiteboard.
>
> Let's wait till Jason wakes up, before jumping to conclusions.
> It was his request to update all ULPs.
We are stuck in a bad spot here
Only the kernel can universally support ACCESS_RELAXED_ORDERING
because all the ULPs are required to work sanely already, but
userspace does not have this limitation and we know of enough popular
verbs users that will break if we unconditionally switch on
ACCESS_RELAXED_ORDERING.
Further, we have the problem with the FMR interface that technically
lets the caller control the entire access_flags, including
ACCESS_RELAXED_ORDERING.
So we broadly have two choice
1) Diverge the kernel and user interfaces and make the RDMA drivers
special case all the kernel stuff to force
ACCESS_RELAXED_ORDERING when they are building MRs and processing
FMR WQE's
2) Keep the two interfaces the same and push the
ACCESS_RELAXED_ORDERING to a couple of places in the ULPs so the
drivers see a consistent API
They are both poor choices, but I think #2 has a greater chance of
everyone doing their parts correctly.
Jason
