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:

quoted

On Tue, 2018-03-13 at 13:45 -0700, David Ahern wrote:

quoted

On 3/13/18 1:32 AM, Leon Romanovsky wrote:

quoted

On Mon, Mar 12, 2018 at 10:53:03AM -0700, David Ahern wrote:

quoted

On 3/12/18 8:16 AM, Steve Wise wrote:

quoted

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.