Re: [PATCH v2 iproute2-next 0/6] cm_id, cq, mr, and pd resource tracking

[Doug Ledford <dledford@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

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.

>  I do not need the overhead of
> sometimes I sync the rdma header file and sometimes I don't.
> 
> One option that comes to mind is to move the rdma header file under the
> rdma directory. It breaks the uapi model, but it seems that iproute2 is
> just a delivery vehicle for this command.



-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]