Re: linux-next: manual merge of the block tree with the rdma tree

[Jens Axboe]

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