[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bccadc63-6b10-ac6b-595f-9a97a57c9888@redhat.com>
Date: Tue, 20 Mar 2018 13:21:28 -0400
From: Doug Ledford <dledford@...hat.com>
To: David Ahern <dsahern@...il.com>, Leon Romanovsky <leon@...nel.org>,
stephen@...workplumber.org
Cc: Steve Wise <swise@...ngridcomputing.com>, netdev@...r.kernel.org,
linux-rdma@...r.kernel.org
Subject: Re: [PATCH v2 iproute2-next 0/6] cm_id, cq, mr, and pd resource
tracking
On 3/16/2018 12:18 PM, David Ahern wrote:
> On 3/13/18 1:58 PM, Doug Ledford wrote:
>> On Tue, 2018-03-13 at 13:45 -0700, David Ahern wrote:
>>> On 3/13/18 1:32 AM, Leon Romanovsky wrote:
>>>> On Mon, Mar 12, 2018 at 10:53:03AM -0700, David Ahern wrote:
>>>>> On 3/12/18 8:16 AM, Steve Wise wrote:
>>>>>> Hey all,
>>>>>>
>>>>>> The kernel side of this series has been merged for rdma-next [1]. Let me
>>>>>> know if this iproute2 series can be merged, of if it needs more changes.
>>>>>>
>>>>>
>>>>> The problem is that iproute2 headers are synced to kernel headers from
>>>>> DaveM's tree (net-next mainly). I take it this series will not appear in
>>>>> Dave's tree until after a merge through Linus' tree. Correct?
>>>>
>>>> David,
>>>>
>>>> Technically, you are right, and we would like to ask you for an extra tweak
>>>> to the flow for the RDMAtool, because current scheme causes delays at least
>>>> cycle.
>>>>
>>>> Every RDMAtool's patchset which requires changes to headers is always
>>>> includes header patch, can you please accept those series and once you
>>>> are bringing new net-next headers from Linus, simply overwrite all our
>>>> headers?
>>>
>>> I did not follow the discussion back when this decision was made, so how
>>> did rdma tool end up in iproute2?
>>
>> It is modeled after the ip command, and for better or worse, the
>> iproute2 package has become the standard drop box for low level kernel
>> network configuring tools. The RDMA subsystem may not be IP networking,
>> but it is still networking, so it seemed an appropriate fit.
>
> why doesn't the rdma tree go through Dave then?
>
Because it doesn't use the core network stack hardly at all. It creates
netdevs when it needs to bridge the two stacks, but otherwise the RDMA
subsystem core is apart and unique from the network stack Dave manages.
When I said it was networking, I meant it literally. The RDMA fabrics
are networks. It wasn't meant to imply that they shared anything
substantial in common with the typical Ethernet/IP networking that is
the core of what Dave manages.
Download attachment "signature.asc" of type "application/pgp-signature" (899 bytes)
Powered by blists - more mailing lists