| Message ID | cover.1520020530.git.swise@opengridcomputing.com |
|---|---|
| Headers | show |
| Series | cm_id, cq, mr, and pd resource tracking | expand |
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-owner@vger.kernel.org [mailto:linux-rdma- > owner@vger.kernel.org] On Behalf Of Steve Wise > Sent: Friday, March 02, 2018 1:56 PM > To: dsahern@gmail.com > Cc: leon@kernel.org; stephen@networkplumber.org; netdev@vger.kernel.org; > linux-rdma@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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
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?
> > 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.
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 >
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.
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.
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
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?
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
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.
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?
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
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.
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.
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.
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.