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

[David Ahern]

On 3/22/18 2:20 PM, Steve Wise wrote:
>> I think the simplest approach is to move the uapi header under the rdma
>> directory and you folks take ownership of that header.
> Fine with me.  Leon?  

Please make a patch moving the existing file and then make changes to it
in follow on patches.

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

[Steve Wise]

On 3/21/2018 11:59 AM, David Ahern wrote:
> On 3/20/18 11:21 AM, Doug Ledford wrote:
>> 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.
>>
> I think the simplest approach is to move the uapi header under the rdma
> directory and you folks take ownership of that header.

Fine with me.  Leon?  

Steve.

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

[David Ahern]

On 3/20/18 11:21 AM, Doug Ledford wrote:
> 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.
> 

I think the simplest approach is to move the uapi header under the rdma
directory and you folks take ownership of that header.

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

[Doug Ledford]

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.



signature.asc
Description: OpenPGP digital signature

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

[Leon Romanovsky]

On Fri, Mar 16, 2018 at 09:08:55AM -0700, David Ahern wrote:
> On 3/14/18 8:29 PM, Jason Gunthorpe wrote:
> > On Wed, Mar 14, 2018 at 08:14:53PM -0700, David Ahern wrote:
> >> On 3/13/18 2:13 PM, Jason Gunthorpe wrote:
> >>> Could you pull the uapi headers from linux-next? That tree will have
> >>> both netdev and rdma stuff merged together properly.
> >>
> >> What's the merge history between linux-next, Linus' tree, net-next +
> >> rdma-next?
> >
> > Not sure I understand the question?
> >
> > linux-next is thrown away every cycle, so for instance you can't say
> > "took uapi headers from linux-next commit XYZ" in the iproute git
> > commit..
> >
> > Otherwise, linux-next is built, I think daily/weekly and includes the
> > latest of both rdma and netdev next trees, so it certainly has the
> > right content.
> >
> > A script could figure out the stable netdev and rdma commit IDs from
> > linux-next and record those, if that is interest..
>
> I'd prefer not to sync headers to a tree that disappears; I like the
> traceability to specific points in time.

The headers itself will have real SHAs, the same as netdev and RDMA
trees have, so it will give needed traceability as you are looking.

Thanks


signature.asc
Description: PGP signature

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

[David Ahern]

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?

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

[David Ahern]

On 3/14/18 8:29 PM, Jason Gunthorpe wrote:
> On Wed, Mar 14, 2018 at 08:14:53PM -0700, David Ahern wrote:
>> On 3/13/18 2:13 PM, Jason Gunthorpe wrote:
>>> Could you pull the uapi headers from linux-next? That tree will have
>>> both netdev and rdma stuff merged together properly.
>>
>> What's the merge history between linux-next, Linus' tree, net-next +
>> rdma-next?
> 
> Not sure I understand the question?
> 
> linux-next is thrown away every cycle, so for instance you can't say
> "took uapi headers from linux-next commit XYZ" in the iproute git
> commit..
> 
> Otherwise, linux-next is built, I think daily/weekly and includes the
> latest of both rdma and netdev next trees, so it certainly has the
> right content.
> 
> A script could figure out the stable netdev and rdma commit IDs from
> linux-next and record those, if that is interest..

I'd prefer not to sync headers to a tree that disappears; I like the
traceability to specific points in time.

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

[Jason Gunthorpe]

On Wed, Mar 14, 2018 at 08:14:53PM -0700, David Ahern wrote:
> On 3/13/18 2:13 PM, Jason Gunthorpe wrote:
> > Could you pull the uapi headers from linux-next? That tree will have
> > both netdev and rdma stuff merged together properly.
> 
> What's the merge history between linux-next, Linus' tree, net-next +
> rdma-next?

Not sure I understand the question?

linux-next is thrown away every cycle, so for instance you can't say
"took uapi headers from linux-next commit XYZ" in the iproute git
commit..

Otherwise, linux-next is built, I think daily/weekly and includes the
latest of both rdma and netdev next trees, so it certainly has the
right content.

A script could figure out the stable netdev and rdma commit IDs from
linux-next and record those, if that is interest..

Jason

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

[David Ahern]

On 3/13/18 2:13 PM, Jason Gunthorpe wrote:
> Could you pull the uapi headers from linux-next? That tree will have
> both netdev and rdma stuff merged together properly.

What's the merge history between linux-next, Linus' tree, net-next +
rdma-next?

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

[Jason Gunthorpe]

On Tue, Mar 13, 2018 at 01:45:12PM -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? I do not need the overhead of
> sometimes I sync the rdma header file and sometimes I don't.

Could you pull the uapi headers from linux-next? That tree will have
both netdev and rdma stuff merged together properly.

Jason

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

[Doug Ledford]

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 
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

signature.asc
Description: This is a digitally signed message part

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

[David Ahern]

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? 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.

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

[Leon Romanovsky]

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?

Thanks

>


signature.asc
Description: PGP signature

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

[Steve Wise]

> 
> 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?

Yes, I think so.

Steve.

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

[David Ahern]

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?

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

[Steve Wise]

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.

Thanks,

Steve.

[1] https://www.spinics.net/lists/linux-rdma/msg61720.html



> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> ow...@vger.kernel.org] On Behalf Of Steve Wise
> Sent: Friday, March 02, 2018 1:56 PM
> To: dsah...@gmail.com
> Cc: l...@kernel.org; step...@networkplumber.org; netdev@vger.kernel.org;
> linux-r...@vger.kernel.org
> Subject: [PATCH v2 iproute2-next 0/6] cm_id, cq, mr, and pd resource
tracking
> 
> Hello,
> 
> This series enhances the iproute2 rdma tool to include dumping of
> connection manager id (cm_id), completion queue (cq), memory region (mr),
> and protection domain (pd) rdma resources.  It is the user-space part of
> the resource tracking series under review now on the linux-rdma list [1].
> 
> Changes since v1/RFC:
> - removed RFC tag
> - initialize rd properly to avoid passing a garbage port number
> - revert accidental change to qp_valid_filters
> - removed cm_id dev/network/transport types
> - cm_id ip addrs now passed up as __kernel_sockaddr_storage
> - cm_id ip address ports printed as "address:port" strings
> - only parse/display memory keys and iova if available
> - filter on "users" for cqs and pds
> - fixed memory leaks
> - removed PD_FLAGS attribute
> - filter on "mrlen" for mrs
> - filter on "poll-ctx" for cqs
> - don't require addrs or qp_type for parsing cm_ids
> - only filter optional attrs if they are present
> - remove PGSIZE MR attr to match kernel
> 
> [1] https://www.spinics.net/lists/linux-rdma/msg61400.html
> 
> Thanks,
> 
> Steve.
> ---
> 
> Steve Wise (6):
>   rdma: update rdma_netlink.h
>   rdma: initialize the rd struct
>   rdma: Add CM_ID resource tracking information
>   rdma: Add CQ resource tracking information
>   rdma: Add MR resource tracking information
>   rdma: Add PD resource tracking information
> 
>  include/json_writer.h|   2 +
>  include/uapi/rdma/rdma_netlink.h |  44 ++-
>  lib/json_writer.c|  11 +
>  rdma/rdma.c  |   2 +-
>  rdma/rdma.h  |   2 +
>  rdma/res.c   | 611
++-
>  rdma/utils.c |  16 +
>  7 files changed, 683 insertions(+), 5 deletions(-)
> 
> --
> 1.8.3.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html