On 6/2/20 1:09 PM, Jason Gunthorpe wrote: > On Tue, Jun 02, 2020 at 01:02:55PM -0600, Jens Axboe wrote: >> On 6/2/20 1:01 PM, Jason Gunthorpe wrote: >>> On Tue, Jun 02, 2020 at 11:37:26AM +0300, Max Gurtovoy wrote: >>>> >>>> On 6/2/2020 5:56 AM, Stephen Rothwell wrote: >>>>> Hi all, >>>> >>>> Hi, >>>> >>>> This looks good to me. >>>> >>>> Can you share a pointer to the tree so we'll test it in our labs ? >>>> >>>> need to re-test: >>>> >>>> 1. srq per core >>>> >>>> 2. srq per core + T10-PI >>>> >>>> And both will run with shared CQ. >>> >>> Max, this is too much conflict to send to Linus between your own >>> patches. I am going to drop the nvme part of this from RDMA. >>> >>> Normally I don't like applying partial series, but due to this tree >>> split, you can send the rebased nvme part through the nvme/block tree >>> at rc1 in two weeks.. >> >> Was going to comment that this is probably how it should have been >> done to begin with. If we have multiple conflicts like that between >> two trees, someone is doing something wrong... > > Well, on the other hand having people add APIs in one tree and then > (promised) consumers in another tree later on has proven problematic > in the past. It is best to try to avoid that, but in this case I don't > think Max will have any delay to get the API consumer into nvme in two > weeks. Having conflicting trees is a problem. If there's a dependency for two trees for some new work, then just have a separate branch that's built on those two. For NVMe core work, then it should include the pending NVMe changes. -- Jens Axboe
