cm_id, cq, mr, and pd resource tracking

Initialize the rd struct so port_idx is 0 unless set otherwise. Otherwise, strict_port queries end up passing an uninitialized PORT nlattr.

Signed-off-by Steve Wise <[email protected]>

---
 rdma/rdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Sample output:

# rdma resource
2: cxgb4_0: pd 5 cq 2 qp 2 cm_id 3 mr 7
3: mlx4_0: pd 7 cq 3 qp 3 cm_id 3 mr 7

# rdma resource show cm_id
link cxgb4_0/- lqpn 0 qp-type RC state LISTEN ps TCP pid 30485 comm rping src-addr 0.0.0.0:7174
link cxgb4_0/2 lqpn 1048 qp-type RC state CONNECT ps TCP pid 30503 comm rping src-addr 172.16.2.1:7174 dst-addr 172.16.2.1:38246
link cxgb4_0/2 lqpn 1040 qp-type RC state CONNECT ps TCP pid 30498 comm rping src-addr 172.16.2.1:38246 dst-addr 172.16.2.1:7174
link mlx4_0/- lqpn 0 qp-type RC state LISTEN ps TCP pid 30485 comm rping src-addr 0.0.0.0:7174
link mlx4_0/1 lqpn 539 qp-type RC state CONNECT ps TCP pid 30494 comm rping src-addr 172.16.99.1:7174 dst-addr 172.16.99.1:43670
link mlx4_0/1 lqpn 538 qp-type RC state CONNECT ps TCP pid 30492 comm rping src-addr 172.16.99.1:43670 dst-addr 172.16.99.1:7174

# rdma resource show cm_id dst-port 7174
link cxgb4_0/2 lqpn 1040 qp-type RC state CONNECT ps TCP pid 30498 comm rping src-addr 172.16.2.1:38246 dst-addr 172.16.2.1:7174
link mlx4_0/1 lqpn 538 qp-type RC state CONNECT ps TCP pid 30492 comm rping src-addr 172.16.99.1:43670 dst-addr 172.16.99.1:7174

Signed-off-by Steve Wise <[email protected]>

---
 rdma/rdma.h  |   2 +
 rdma/res.c   | 258 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 rdma/utils.c |   5 ++
 3 files changed, 264 insertions(+), 1 deletion(-)

Quoted 8 lines

Sample output:

# rdma resource
2: cxgb4_0: pd 5 cq 2 qp 2 cm_id 3 mr 7
3: mlx4_0: pd 7 cq 3 qp 3 cm_id 3 mr 7

# rdma resource show cm_id
link cxgb4_0/- lqpn 0 qp-type RC state LISTEN ps TCP pid 30485 comm

rping src-addr 0.0.0.0:7174

Quoted 1 line

link cxgb4_0/2 lqpn 1048 qp-type RC state CONNECT ps TCP pid 30503

comm rping src-addr 172.16.2.1:7174 dst-addr 172.16.2.1:38246

Quoted 1 line

link cxgb4_0/2 lqpn 1040 qp-type RC state CONNECT ps TCP pid 30498

comm rping src-addr 172.16.2.1:38246 dst-addr 172.16.2.1:7174

Quoted 1 line

link mlx4_0/- lqpn 0 qp-type RC state LISTEN ps TCP pid 30485 comm rping

src-addr 0.0.0.0:7174

Quoted 1 line

link mlx4_0/1 lqpn 539 qp-type RC state CONNECT ps TCP pid 30494

comm rping src-addr 172.16.99.1:7174 dst-addr 172.16.99.1:43670

Quoted 1 line

link mlx4_0/1 lqpn 538 qp-type RC state CONNECT ps TCP pid 30492

comm rping src-addr 172.16.99.1:43670 dst-addr 172.16.99.1:7174

Quoted 3 lines

# rdma resource show cm_id dst-port 7174
link cxgb4_0/2 lqpn 1040 qp-type RC state CONNECT ps TCP pid 30498

comm rping src-addr 172.16.2.1:38246 dst-addr 172.16.2.1:7174

Quoted 1 line

link mlx4_0/1 lqpn 538 qp-type RC state CONNECT ps TCP pid 30492

comm rping src-addr 172.16.99.1:43670 dst-addr 172.16.99.1:7174

Quoted 5 lines

Signed-off-by Steve Wise <[email protected]>

---
 rdma/rdma.h  |   2 +
 rdma/res.c   | 258

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-

Quoted 3 lines

 rdma/utils.c |   5 ++
 3 files changed, 264 insertions(+), 1 deletion(-)

Steve, can you please add man pages update as a followup to this series?

Especially the fact that you are providing dst-port filter option should be mentioned.

Thanks,

Reviewed-by Leon Romanovsky <[email protected]>

rdma/rdma.h +0 -0

index 5809f70..e55205b 100644

Quoted 10 lines · Steve Wise

rdma/rdma.h +1 -0

index 5809f70..e55205b 100644
@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 

rdma/rdma.h line 27

Quoted 5 lines

rdma/rdma.h +1 -0

 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 11 lines · David Ahern

Quoted 10 lines · Steve Wise

rdma/rdma.h +1 -0

index 5809f70..e55205b 100644
@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 

Quoted 6 lines

rdma/rdma.h line 27

Quoted 5 lines

rdma/rdma.h +1 -0

 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

Quoted 19 lines · Steve Wise

Quoted 17 lines · David Ahern

Quoted 5 lines · Steve Wise

rdma/rdma.h +0 -0

index 5809f70..e55205b 100644

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 3 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

You need to add a check for the package, and only build rdma if that package is installed. See check_mnl in configure for an example.

Quoted 20 lines · David Ahern

Quoted 19 lines · Steve Wise

Quoted 17 lines · David Ahern

Quoted 5 lines · Steve Wise

rdma/rdma.h +0 -0

index 5809f70..e55205b 100644

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 5 lines

Quoted 3 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

You need to add a check for the package, and only build rdma if that package is installed. See check_mnl in configure for an example.

Ok, that makes sense.

Steve.

Quoted 21 lines · Steve Wise

Quoted 19 lines · David Ahern

Quoted 18 lines · Steve Wise

Quoted 17 lines · David Ahern

Quoted 5 lines · Steve Wise

rdma/rdma.h +0 -0

index 5809f70..e55205b 100644

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

You need to add a check for the package, and only build rdma if that package is installed. See check_mnl in configure for an example.

Ok, that makes sense.

IMHO, better solution will be to copy those files to iproute2.

Quoted 27 lines · Leon Romanovsky

Quoted 26 lines · Steve Wise

Quoted 24 lines · David Ahern

Quoted 12 lines · Steve Wise

Quoted 11 lines · David Ahern

Quoted 10 lines · Steve Wise

rdma/rdma.h +1 -0

index 5809f70..e55205b 100644
@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 

Quoted 9 lines

Quoted 6 lines

rdma/rdma.h line 27

Quoted 5 lines

rdma/rdma.h +1 -0

 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

You need to add a check for the package, and only build rdma if that package is installed. See check_mnl in configure for an example.

Quoted 2 lines

Quoted 1 line

Ok, that makes sense.

IMHO, better solution will be to copy those files to iproute2.

Hey Leon,

Why is it better in your opinion?  My gut tells me adding rdma_cma.h to iproute2 means more uabi type syncing.

Quoted 32 lines · Steve Wise

Quoted 21 lines · Leon Romanovsky

Quoted 20 lines · Steve Wise

Quoted 19 lines · David Ahern

Quoted 18 lines · Steve Wise

Quoted 17 lines · David Ahern

Quoted 5 lines · Steve Wise

rdma/rdma.h +0 -0

index 5809f70..e55205b 100644

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 7 lines

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

You need to add a check for the package, and only build rdma if that package is installed. See check_mnl in configure for an example.

Ok, that makes sense.

IMHO, better solution will be to copy those files to iproute2.

Hey Leon,

Quoted 2 lines

Why is it better in your opinion?  My gut tells me adding rdma_cma.h to iproute2 means more uabi type syncing.

Making rdmatool be dependant on rdma-core will require that distributions will update their specs to install rdma-core as a dependency for every iprotue2 install.

The rdma-core dependency makes sense for RDMA users, but doesn't for most of the iproute2 users.

Quoted 33 lines · Leon Romanovsky

Quoted 32 lines · Steve Wise

Quoted 21 lines · Leon Romanovsky

Quoted 20 lines · Steve Wise

Quoted 19 lines · David Ahern

Quoted 18 lines · Steve Wise

Quoted 17 lines · David Ahern

Quoted 5 lines · Steve Wise

rdma/rdma.h +0 -0

index 5809f70..e55205b 100644

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 7 lines

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

You need to add a check for the package, and only build rdma if that package is installed. See check_mnl in configure for an example.

Ok, that makes sense.

IMHO, better solution will be to copy those files to iproute2.

Hey Leon,

Quoted 8 lines

Quoted 2 lines

Why is it better in your opinion?  My gut tells me adding rdma_cma.h to iproute2 means more uabi type syncing.

Making rdmatool be dependant on rdma-core will require that distributions will update their specs to install rdma-core as a dependency for every iprotue2 install.

The rdma-core dependency makes sense for RDMA users, but doesn't for most of the iproute2 users.

I'm fuzzy on the details of distro packaging, but David's suggestion is that rdmatool wouldn't get built if rdma-core isn't present. But everything else would.  Just like it does not get built if libmnl is not installed.  For pre-built rpms, the rdma-core would have to be present.

I'm ok pulling it in, I'm just trying to understand. :)

Steve.

Quoted 10 lines · David Ahern

Quoted 9 lines · Steve Wise

rdma/rdma.h +2 -0

index 5809f70..e55205b 100644
+++ b/rdma/rdma.h

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 

Quoted 6 lines

rdma/rdma.h line 27

Quoted 5 lines

rdma/rdma.h +1 -0

 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

Quoted 18 lines · Steve Wise

Quoted 16 lines · David Ahern

Quoted 4 lines · Steve Wise

rdma/rdma.h +1 -0

index 5809f70..e55205b 100644
+++ b/rdma/rdma.h

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 2 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an include/uapi/rdma header

Fix it there and don't try to use rdma-core headers to get kernel ABI.

Jason

Quoted 19 lines · Jason Gunthorpe

Quoted 18 lines · Steve Wise

Quoted 16 lines · David Ahern

Quoted 4 lines · Steve Wise

rdma/rdma.h +1 -0

index 5809f70..e55205b 100644
+++ b/rdma/rdma.h

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 7 lines

Quoted 2 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an include/uapi/rdma header

Fix it there and don't try to use rdma-core headers to get kernel ABI.

Jason

I wish you'd commented on this just a little sooner.  I just resent v3 of this series... with rdma_cma.h included. :)

How about the restrack/nldev code just translates the port space from enum rdma_port_space to a new ABI enum, say nldev_rdma_port_space, that i add to rdma_netlink.h?  I'd hate to open the can of worms of trying to split rdma_cma.h into uabi and no uabi headers. :(

Quoted 29 lines · Steve Wise

Quoted 19 lines · Jason Gunthorpe

Quoted 18 lines · Steve Wise

Quoted 16 lines · David Ahern

Quoted 4 lines · Steve Wise

rdma/rdma.h +1 -0

index 5809f70..e55205b 100644
+++ b/rdma/rdma.h

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 7 lines

Quoted 2 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an include/uapi/rdma header

Fix it there and don't try to use rdma-core headers to get kernel ABI.

Jason

Quoted 7 lines

I wish you'd commented on this just a little sooner.  I just resent v3 of this series... with rdma_cma.h included. :)

How about the restrack/nldev code just translates the port space from enum rdma_port_space to a new ABI enum, say nldev_rdma_port_space, that i add to rdma_netlink.h?  I'd hate to open the can of worms of trying to split rdma_cma.h into uabi and no uabi headers. :(

If port space is already part of the ABI there isn't much reason to translate it.

You just need to pick the right header to put it in, since it is a verbs define it doesn't belong in the netlink header.

Jason

Quoted 41 lines · Jason Gunthorpe

Quoted 29 lines · Steve Wise

Quoted 19 lines · Jason Gunthorpe

Quoted 18 lines · Steve Wise

Quoted 16 lines · David Ahern

Quoted 4 lines · Steve Wise

rdma/rdma.h +1 -0

index 5809f70..e55205b 100644
+++ b/rdma/rdma.h

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 7 lines

Quoted 2 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an include/uapi/rdma header

Fix it there and don't try to use rdma-core headers to get kernel ABI.

Jason

Quoted 7 lines

I wish you'd commented on this just a little sooner.  I just resent v3 of this series... with rdma_cma.h included. :)

How about the restrack/nldev code just translates the port space from enum rdma_port_space to a new ABI enum, say nldev_rdma_port_space, that i add to rdma_netlink.h?  I'd hate to open the can of worms of trying to split rdma_cma.h into uabi and no uabi headers. :(

If port space is already part of the ABI there isn't much reason to translate it.

Quoted 2 lines

You just need to pick the right header to put it in, since it is a verbs define it doesn't belong in the netlink header.

I completely understand Steve's concerns.

I tried to do such thing (expose kernel headers) in first incarnation of rdmatool with attempt to clean IB/core as well to ensure that we won't expose anything that is not implemented. It didn't go well.

Quoted 45 lines · Leon Romanovsky

Quoted 43 lines · Jason Gunthorpe

Quoted 29 lines · Steve Wise

Quoted 19 lines · Jason Gunthorpe

Quoted 18 lines · Steve Wise

Quoted 16 lines · David Ahern

Quoted 4 lines · Steve Wise

rdma/rdma.h +1 -0

index 5809f70..e55205b 100644
+++ b/rdma/rdma.h

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 7 lines

Quoted 2 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an include/uapi/rdma header

Fix it there and don't try to use rdma-core headers to get kernel ABI.

Jason

Quoted 7 lines

I wish you'd commented on this just a little sooner.  I just resent v3 of this series... with rdma_cma.h included. :)

How about the restrack/nldev code just translates the port space from enum rdma_port_space to a new ABI enum, say nldev_rdma_port_space, that i add to rdma_netlink.h?  I'd hate to open the can of worms of trying to split rdma_cma.h into uabi and no uabi headers. :(

If port space is already part of the ABI there isn't much reason to translate it.

You just need to pick the right header to put it in, since it is a verbs define it doesn't belong in the netlink header.

Quoted 5 lines

I completely understand Steve's concerns.

I tried to do such thing (expose kernel headers) in first incarnation of rdmatool with attempt to clean IB/core as well to ensure that we won't expose anything that is not implemented. It didn't go well.

rdma-core is now using the kernel uapi/ headers natively, seems to be going OK. What problem did you face?

Jason

Quoted 46 lines · Jason Gunthorpe

Quoted 45 lines · Leon Romanovsky

Quoted 43 lines · Jason Gunthorpe

Quoted 29 lines · Steve Wise

Quoted 19 lines · Jason Gunthorpe

Quoted 18 lines · Steve Wise

Quoted 16 lines · David Ahern

Quoted 4 lines · Steve Wise

rdma/rdma.h +1 -0

index 5809f70..e55205b 100644
+++ b/rdma/rdma.h

rdma/rdma.h line 27

Quoted 10 lines

rdma/rdma.h +2 -0

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my repo.

Quoted 7 lines

Quoted 2 lines

It is provided by the rdma-core package, upon which rdma tool now depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an include/uapi/rdma header

Fix it there and don't try to use rdma-core headers to get kernel ABI.

Jason

Quoted 7 lines

I wish you'd commented on this just a little sooner.  I just resent v3 of this series... with rdma_cma.h included. :)

How about the restrack/nldev code just translates the port space from enum rdma_port_space to a new ABI enum, say nldev_rdma_port_space, that i add to rdma_netlink.h?  I'd hate to open the can of worms of trying to split rdma_cma.h into uabi and no uabi headers. :(

If port space is already part of the ABI there isn't much reason to translate it.

You just need to pick the right header to put it in, since it is a verbs define it doesn't belong in the netlink header.

Quoted 8 lines

Quoted 5 lines

I completely understand Steve's concerns.

I tried to do such thing (expose kernel headers) in first incarnation of rdmatool with attempt to clean IB/core as well to ensure that we won't expose anything that is not implemented. It didn't go well.

rdma-core is now using the kernel uapi/ headers natively, seems to be going OK. What problem did you face?

I didn't agree to move to UAPI defines which are not implemented and not used in the kernel, so I sent small number of patches similar to those [1, 2].

Those patches were rejected.

So please don't mix Steve's need to use 3 defines with very large and painful task to expose proper UAPIs.

Quoted 19 lines · Jason Gunthorpe

Quoted 18 lines · Leon Romanovsky

Quoted 17 lines · Jason Gunthorpe

Quoted 16 lines · Steve Wise

Quoted 15 lines · Jason Gunthorpe

Quoted 13 lines · Steve Wise

Quoted 12 lines · David Ahern

Quoted 10 lines · Steve Wise

Quoted 9 lines

rdma/rdma.h +2 -0

index 5809f70..e55205b 100644
+++ b/rdma/rdma.h

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

rdma/rdma.h line 27

Quoted 5 lines

rdma/rdma.h +1 -0

 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my

repo.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

It is provided by the rdma-core package, upon which rdma tool

now

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 1 line

depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an include/uapi/rdma

header

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Fix it there and don't try to use rdma-core headers to get kernel

ABI.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

Jason

I wish you'd commented on this just a little sooner. I just resent

v3

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

of this series... with rdma_cma.h included. :)

How about the restrack/nldev code just translates the port space

from

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

enum rdma_port_space to a new ABI enum, say

nldev_rdma_port_space, that

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

i add to rdma_netlink.h? I'd hate to open the can of worms of

trying to

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

split rdma_cma.h into uabi and no uabi headers. :(

If port space is already part of the ABI there isn't much reason to translate it.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 2 lines

You just need to pick the right header to put it in, since it is a verbs define it doesn't belong in the netlink header.

I completely understand Steve's concerns.

I tried to do such thing (expose kernel headers) in first incarnation of rdmatool with attempt to clean IB/core as well to ensure that we

won't expose

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

anything that is not implemented. It didn't go well.

rdma-core is now using the kernel uapi/ headers natively, seems to be going OK. What problem did you face?

I didn't agree to move to UAPI defines which are not implemented and

not

Quoted 1 line

used in the kernel, so I sent small number of patches similar to those [1,

2].

Quoted 3 lines

Those patches were rejected.

Quoted 2 lines

So please don't mix Steve's need to use 3 defines with very large and painful task to expose proper UAPIs.

Steve can just move the 3 defines he needs to the uapi, we are doing this incrementally..

rdma_core does not define kernel ABI and it is totally wrong to use random constants from rdma_cma.h as kernel ABI.

Quoted 75 lines · Leon Romanovsky

Quoted 19 lines · Jason Gunthorpe

Quoted 18 lines · Leon Romanovsky

Quoted 17 lines · Jason Gunthorpe

Quoted 16 lines · Steve Wise

Quoted 15 lines · Jason Gunthorpe

Quoted 13 lines · Steve Wise

Quoted 12 lines · David Ahern

Quoted 10 lines · Steve Wise

Quoted 9 lines

rdma/rdma.h +2 -0

index 5809f70..e55205b 100644
+++ b/rdma/rdma.h

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

rdma/rdma.h line 27

Quoted 5 lines

rdma/rdma.h +1 -0

 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file in my

repo.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

It is provided by the rdma-core package, upon which rdma tool

now

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 1 line

depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an include/uapi/rdma

header

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Fix it there and don't try to use rdma-core headers to get kernel

ABI.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

Jason

I wish you'd commented on this just a little sooner. I just resent

v3

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

of this series... with rdma_cma.h included. :)

How about the restrack/nldev code just translates the port space

from

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

enum rdma_port_space to a new ABI enum, say

nldev_rdma_port_space, that

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

i add to rdma_netlink.h? I'd hate to open the can of worms of

trying to

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

split rdma_cma.h into uabi and no uabi headers. :(

If port space is already part of the ABI there isn't much reason to translate it.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 2 lines

You just need to pick the right header to put it in, since it is a verbs define it doesn't belong in the netlink header.

I completely understand Steve's concerns.

I tried to do such thing (expose kernel headers) in first incarnation of rdmatool with attempt to clean IB/core as well to ensure that we

won't expose

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

anything that is not implemented. It didn't go well.

rdma-core is now using the kernel uapi/ headers natively, seems to be going OK. What problem did you face?

I didn't agree to move to UAPI defines which are not implemented and

not

Quoted 1 line

used in the kernel, so I sent small number of patches similar to those [1,

2].

Quoted 3 lines

Those patches were rejected.

Quoted 9 lines

Quoted 2 lines

So please don't mix Steve's need to use 3 defines with very large and painful task to expose proper UAPIs.

Steve can just move the 3 defines he needs to the uapi, we are doing this incrementally..

rdma_core does not define kernel ABI and it is totally wrong to use random constants from rdma_cma.h as kernel ABI.

Proposal:

Since the cm_id port space is part of the rdma_ucm_create_id struct in include/uapi/rdma/rdma_user_cm.h, I'll move the rdma_port_space enum there. And then my iproute2 series will have to add a copy of rdma_user_cm.h locally into rdma/include/uapi/rdma, right?

Will that work for everyone?

Steve.

Quoted 5 lines

Quoted 5 lines · Leon Romanovsky

Quoted 2 lines · Jason Gunthorpe

Quoted 1 line

On Tue, Mar 27, 2018 at 06:21:41AM +0300, Leon Romanovsky

Quoted 1 line · wrote:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Mon, Mar 26, 2018 at 04:30:33PM -0600, Jason Gunthorpe

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines · Steve Wise

Quoted 3 lines · Jason Gunthorpe

Quoted 1 line

On Mon, Mar 26, 2018 at 09:30:41AM -0500, Steve Wise

Quoted 12 lines · wrote:

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines · David Ahern

Quoted 10 lines · Steve Wise

Quoted 9 lines

rdma/rdma.h +2 -0

index 5809f70..e55205b 100644
+++ b/rdma/rdma.h

@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

rdma/rdma.h line 27

Quoted 5 lines

rdma/rdma.h +1 -0

 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 

did you forget to add rdma_cma.h? I don't see that file

my

Quoted 2 lines

Quoted 2 lines

repo.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

It is provided by the rdma-core package, upon which rdma

tool

Quoted 3 lines

Quoted 3 lines

now

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 1 line

depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an

Quoted 3 lines

Quoted 3 lines

header

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Fix it there and don't try to use rdma-core headers to get

kernel

Quoted 4 lines

Quoted 4 lines

ABI.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

Jason

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

I wish you'd commented on this just a little sooner. I just

resent

Quoted 4 lines

Quoted 4 lines

v3

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

of this series... with rdma_cma.h included. :)

How about the restrack/nldev code just translates the port

space

Quoted 4 lines

Quoted 4 lines

from

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

enum rdma_port_space to a new ABI enum, say

nldev_rdma_port_space, that

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

i add to rdma_netlink.h? I'd hate to open the can of worms

Quoted 4 lines

Quoted 4 lines

trying to

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

split rdma_cma.h into uabi and no uabi headers. :(

If port space is already part of the ABI there isn't much

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

translate it.

You just need to pick the right header to put it in, since it

verbs

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

define it doesn't belong in the netlink header.

I completely understand Steve's concerns.

I tried to do such thing (expose kernel headers) in first

of

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

rdmatool with attempt to clean IB/core as well to ensure that we

won't expose

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

anything that is not implemented. It didn't go well.

rdma-core is now using the kernel uapi/ headers natively, seems to

be

Quoted 5 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

going OK. What problem did you face?

I didn't agree to move to UAPI defines which are not implemented and

not

Quoted 1 line

used in the kernel, so I sent small number of patches similar to

[1,

Quoted 5 lines

Quoted 5 lines

2].

Quoted 4 lines

Those patches were rejected.

So please don't mix Steve's need to use 3 defines with very large

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

painful task to expose proper UAPIs.

Steve can just move the 3 defines he needs to the uapi, we are doing this incrementally..

Quoted 7 lines

Quoted 3 lines

rdma_core does not define kernel ABI and it is totally wrong to use random constants from rdma_cma.h as kernel ABI.

Proposal:

Since the cm_id port space is part of the rdma_ucm_create_id struct in

include/uapi/rdma/rdma_user_cm.h, I'll move the rdma_port_space enum there. And then my iproute2 series will have to add a copy of rdma_user_cm.h locally into rdma/include/uapi/rdma, right?

Quoted 1 line

Quoted 1 line

Will that work for everyone?

You need to remove _PS from that structure and from the kernel with justification that it is safe to do.

Thanks

Quoted 26 lines · Steve Wise

Quoted 5 lines

Quoted 5 lines · Leon Romanovsky

Quoted 2 lines · Jason Gunthorpe

Quoted 1 line

On Tue, Mar 27, 2018 at 06:21:41AM +0300, Leon Romanovsky

Quoted 1 line · wrote:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Mon, Mar 26, 2018 at 04:30:33PM -0600, Jason Gunthorpe

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines · Steve Wise

Quoted 3 lines · Jason Gunthorpe

Quoted 1 line

On Mon, Mar 26, 2018 at 09:30:41AM -0500, Steve Wise

Quoted 12 lines · wrote:

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines · David Ahern

Quoted 10 lines · Steve Wise

Quoted 9 lines

diff --git a/rdma/rdma.h b/rdma/rdma.h
index 5809f70..e55205b 100644
+++ b/rdma/rdma.h
@@ -18,10 +18,12 @@
#include <libmnl/libmnl.h>
#include <rdma/rdma_netlink.h>
#include <time.h>
+#include <net/if_arp.h>

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

#include "list.h"
#include "utils.h"
#include "json_writer.h"
+#include <rdma/rdma_cma.h>

did you forget to add rdma_cma.h? I don't see that file

in

Quoted 7 lines

my

Quoted 2 lines

Quoted 2 lines

repo.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

It is provided by the rdma-core package, upon which rdma

tool

Quoted 3 lines

Quoted 3 lines

now

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 1 line

depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an

include/uapi/rdma

Quoted 8 lines

Quoted 3 lines

Quoted 3 lines

header

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Fix it there and don't try to use rdma-core headers to get

kernel

Quoted 4 lines

Quoted 4 lines

ABI.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

Jason

Quoted 11 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

I wish you'd commented on this just a little sooner. I just

resent

Quoted 4 lines

Quoted 4 lines

v3

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

of this series... with rdma_cma.h included. :)

How about the restrack/nldev code just translates the port

space

Quoted 4 lines

Quoted 4 lines

from

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

enum rdma_port_space to a new ABI enum, say

nldev_rdma_port_space, that

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

i add to rdma_netlink.h? I'd hate to open the can of worms

of

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

trying to

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

split rdma_cma.h into uabi and no uabi headers. :(

If port space is already part of the ABI there isn't much

reason to

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

translate it.

You just need to pick the right header to put it in, since it

is a

Quoted 6 lines

verbs

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

define it doesn't belong in the netlink header.

I completely understand Steve's concerns.

I tried to do such thing (expose kernel headers) in first

incarnation

Quoted 12 lines

of

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

rdmatool with attempt to clean IB/core as well to ensure that we

won't expose

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

anything that is not implemented. It didn't go well.

rdma-core is now using the kernel uapi/ headers natively, seems to

be

Quoted 5 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

going OK. What problem did you face?

I didn't agree to move to UAPI defines which are not implemented and

not

Quoted 1 line

used in the kernel, so I sent small number of patches similar to

those

Quoted 6 lines

[1,

Quoted 5 lines

Quoted 5 lines

2].

Quoted 4 lines

Those patches were rejected.

So please don't mix Steve's need to use 3 defines with very large

and

Quoted 18 lines

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

painful task to expose proper UAPIs.

Steve can just move the 3 defines he needs to the uapi, we are doing this incrementally..

Quoted 7 lines

Quoted 3 lines

rdma_core does not define kernel ABI and it is totally wrong to use random constants from rdma_cma.h as kernel ABI.

Proposal:

Since the cm_id port space is part of the rdma_ucm_create_id struct in

include/uapi/rdma/rdma_user_cm.h, I'll move the rdma_port_space enum there. And then my iproute2 series will have to add a copy of rdma_user_cm.h locally into rdma/include/uapi/rdma, right?

Quoted 2 lines

Will that work for everyone?

Quoted 4 lines

You need to remove _PS from that structure and from the kernel with justification that it is safe to do.

Thanks

I'm pretty sure port space is needed. That struct is used to create a user mode cm_id...

Quoted 5 lines

Quoted 5 lines · Steve Wise

Quoted 4 lines

Quoted 4 lines · Leon Romanovsky

Quoted 1 line

On Tue, Mar 27, 2018 at 08:44:55AM -0600, Jason Gunthorpe

Quoted 5 lines · wrote:

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Tue, Mar 27, 2018 at 06:21:41AM +0300, Leon Romanovsky

Quoted 1 line · wrote:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Mon, Mar 26, 2018 at 04:30:33PM -0600, Jason Gunthorpe

Quoted 1 line · wrote:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Mon, Mar 26, 2018 at 04:34:44PM -0500, Steve Wise

Quoted 16 lines · wrote:

Quoted 16 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines · Jason Gunthorpe

Quoted 1 line

On Mon, Mar 26, 2018 at 09:30:41AM -0500, Steve Wise

Quoted 12 lines · wrote:

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines · David Ahern

Quoted 10 lines · Steve Wise

diff --git a/rdma/rdma.h b/rdma/rdma.h
index 5809f70..e55205b 100644
+++ b/rdma/rdma.h
@@ -18,10 +18,12 @@
#include <libmnl/libmnl.h>
#include <rdma/rdma_netlink.h>
#include <time.h>
+#include <net/if_arp.h>

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

#include "list.h"
#include "utils.h"
#include "json_writer.h"
+#include <rdma/rdma_cma.h>

did you forget to add rdma_cma.h? I don't see that

Quoted 4 lines

in

Quoted 3 lines

my

Quoted 2 lines

Quoted 2 lines

repo.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

It is provided by the rdma-core package, upon which

rdma

Quoted 8 lines

Quoted 4 lines

tool

Quoted 3 lines

Quoted 3 lines

now

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 1 line

depends for the rdma_port_space enum.

It is a kernel bug that enum is not in an

include/uapi/rdma

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

header

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Fix it there and don't try to use rdma-core headers to

Quoted 6 lines

Quoted 6 lines

kernel

Quoted 5 lines

Quoted 5 lines

ABI.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

Jason

I wish you'd commented on this just a little sooner. I

Quoted 5 lines

Quoted 5 lines

resent

Quoted 4 lines

Quoted 4 lines

v3

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

of this series... with rdma_cma.h included. :)

How about the restrack/nldev code just translates the

Quoted 5 lines

Quoted 5 lines

space

Quoted 4 lines

Quoted 4 lines

from

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

enum rdma_port_space to a new ABI enum, say

nldev_rdma_port_space, that

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

i add to rdma_netlink.h? I'd hate to open the can of

Quoted 9 lines

of

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

trying to

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

split rdma_cma.h into uabi and no uabi headers. :(

If port space is already part of the ABI there isn't much

reason to

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

translate it.

You just need to pick the right header to put it in, since

Quoted 10 lines

is a

Quoted 6 lines

verbs

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

define it doesn't belong in the netlink header.

I completely understand Steve's concerns.

I tried to do such thing (expose kernel headers) in first

incarnation

Quoted 2 lines

of

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

rdmatool with attempt to clean IB/core as well to ensure

we

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

won't expose

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

anything that is not implemented. It didn't go well.

rdma-core is now using the kernel uapi/ headers natively,

to

Quoted 4 lines

Quoted 4 lines

be

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

going OK. What problem did you face?

I didn't agree to move to UAPI defines which are not implemented

and

Quoted 9 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

not

Quoted 1 line

used in the kernel, so I sent small number of patches similar to

those

Quoted 6 lines

[1,

Quoted 5 lines

Quoted 5 lines

2].

Quoted 4 lines

Those patches were rejected.

So please don't mix Steve's need to use 3 defines with very

Quoted 4 lines

and

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

painful task to expose proper UAPIs.

Steve can just move the 3 defines he needs to the uapi, we are

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

this incrementally..

rdma_core does not define kernel ABI and it is totally wrong to

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

random constants from rdma_cma.h as kernel ABI.

Proposal:

Since the cm_id port space is part of the rdma_ucm_create_id struct

in

Quoted 1 line

Quoted 1 line

include/uapi/rdma/rdma_user_cm.h, I'll move the rdma_port_space

enum

Quoted 11 lines

Quoted 9 lines

there. And then my iproute2 series will have to add a copy of rdma_user_cm.h locally into rdma/include/uapi/rdma, right?

Quoted 2 lines

Will that work for everyone?

You need to remove _PS from that structure and from the kernel with justification that it is safe to do.

Thanks

I'm pretty sure port space is needed. That struct is used to create a

Quoted 1 line

mode cm_id...

Sorry, it is RDMA_PS_SDP.

Thanks

Sample output:

# rdma resource
2: cxgb4_0: pd 5 cq 2 qp 2 cm_id 3 mr 7
3: mlx4_0: pd 7 cq 3 qp 3 cm_id 3 mr 7

# rdma resource show cm_id
link cxgb4_0/- lqpn 0 qp-type RC state LISTEN ps TCP pid 30485 comm rping src-addr 0.0.0.0:7174
link cxgb4_0/2 lqpn 1048 qp-type RC state CONNECT ps TCP pid 30503 comm rping src-addr 172.16.2.1:7174 dst-addr 172.16.2.1:38246
link cxgb4_0/2 lqpn 1040 qp-type RC state CONNECT ps TCP pid 30498 comm rping src-addr 172.16.2.1:38246 dst-addr 172.16.2.1:7174
link mlx4_0/- lqpn 0 qp-type RC state LISTEN ps TCP pid 30485 comm rping src-addr 0.0.0.0:7174
link mlx4_0/1 lqpn 539 qp-type RC state CONNECT ps TCP pid 30494 comm rping src-addr 172.16.99.1:7174 dst-addr 172.16.99.1:43670
link mlx4_0/1 lqpn 538 qp-type RC state CONNECT ps TCP pid 30492 comm rping src-addr 172.16.99.1:43670 dst-addr 172.16.99.1:7174

# rdma resource show cm_id dst-port 7174
link cxgb4_0/2 lqpn 1040 qp-type RC state CONNECT ps TCP pid 30498 comm rping src-addr 172.16.2.1:38246 dst-addr 172.16.2.1:7174
link mlx4_0/1 lqpn 538 qp-type RC state CONNECT ps TCP pid 30492 comm rping src-addr 172.16.99.1:43670 dst-addr 172.16.99.1:7174

Signed-off-by Steve Wise <[email protected]>

---
 rdma/rdma.h  |   2 +
 rdma/res.c   | 258 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 rdma/utils.c |   5 ++
 3 files changed, 264 insertions(+), 1 deletion(-)

rdma/rdma.h +2 -0

index 5809f70..e55205b 100644
@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 
 #define pr_err(args...) fprintf(stderr, ##args)
 #define pr_out(args...) fprintf(stdout, ##args)

rdma/res.c +9 -1

index 62f5c54..1ef4f20 100644
@@ -16,9 +16,11 @@ static int res_help(struct rd *rd)
 {
 	pr_out("Usage: %s resource\n", rd->filename);
 	pr_out("          resource show [DEV]\n");
-	pr_out("          resource show [qp]\n");
+	pr_out("          resource show [qp|cm_id]\n");
 	pr_out("          resource show qp link [DEV/PORT]\n");
 	pr_out("          resource show qp link [DEV/PORT] [FILTER-NAME FILTER-VALUE]\n");
+	pr_out("          resource show cm_id link [DEV/PORT]\n");
+	pr_out("          resource show cm_id link [DEV/PORT] [FILTER-NAME FILTER-VALUE]\n");
 	return 0;
 }
 

@@ -433,6 +435,230 @@ static int res_qp_parse_cb(const struct nlmsghdr *nlh, void *data)
 	return MNL_CB_OK;
 }
 
+static void print_qp_type(struct rd *rd, uint32_t val)
+{
+	if (rd->json_output)
+		jsonw_string_field(rd->jw, "qp-type",
+				   qp_types_to_str(val));
+	else

rdma/res.c +16 -0

@@ -457,11 +683,41 @@ filters qp_valid_filters[MAX_NUMBER_OF_FILTERS] = {{ .name = "link",
 
 RES_FUNC(res_qp,	RDMA_NLDEV_CMD_RES_QP_GET, qp_valid_filters, false);
 
+static const struct
+filters cm_id_valid_filters[MAX_NUMBER_OF_FILTERS] = {{ .name = "link",
+						   .is_number = false },
+						   { .name = "lqpn",
+						   .is_number = true },
+						   { .name = "qp-type",
+						   .is_number = false },
+						   { .name = "state",
+						   .is_number = false },
+						   { .name = "ps",
+						   .is_number = false },
+						   { .name = "dev-type",
+						   .is_number = false },
+						   { .name = "transport-type",
+						   .is_number = false },
+						   { .name = "pid",

Quoted 74 lines · Steve Wise

Sample output:

# rdma resource
2: cxgb4_0: pd 5 cq 2 qp 2 cm_id 3 mr 7
3: mlx4_0: pd 7 cq 3 qp 3 cm_id 3 mr 7

# rdma resource show cm_id
link cxgb4_0/- lqpn 0 qp-type RC state LISTEN ps TCP pid 30485 comm rping src-addr 0.0.0.0:7174
link cxgb4_0/2 lqpn 1048 qp-type RC state CONNECT ps TCP pid 30503 comm rping src-addr 172.16.2.1:7174 dst-addr 172.16.2.1:38246
link cxgb4_0/2 lqpn 1040 qp-type RC state CONNECT ps TCP pid 30498 comm rping src-addr 172.16.2.1:38246 dst-addr 172.16.2.1:7174
link mlx4_0/- lqpn 0 qp-type RC state LISTEN ps TCP pid 30485 comm rping src-addr 0.0.0.0:7174
link mlx4_0/1 lqpn 539 qp-type RC state CONNECT ps TCP pid 30494 comm rping src-addr 172.16.99.1:7174 dst-addr 172.16.99.1:43670
link mlx4_0/1 lqpn 538 qp-type RC state CONNECT ps TCP pid 30492 comm rping src-addr 172.16.99.1:43670 dst-addr 172.16.99.1:7174

# rdma resource show cm_id dst-port 7174
link cxgb4_0/2 lqpn 1040 qp-type RC state CONNECT ps TCP pid 30498 comm rping src-addr 172.16.2.1:38246 dst-addr 172.16.2.1:7174
link mlx4_0/1 lqpn 538 qp-type RC state CONNECT ps TCP pid 30492 comm rping src-addr 172.16.99.1:43670 dst-addr 172.16.99.1:7174

Signed-off-by Steve Wise <[email protected]>

---
 rdma/rdma.h  |   2 +
 rdma/res.c   | 258 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 rdma/utils.c |   5 ++
 3 files changed, 264 insertions(+), 1 deletion(-)

rdma/rdma.h +2 -0

index 5809f70..e55205b 100644
@@ -18,10 +18,12 @@
 #include <libmnl/libmnl.h>
 #include <rdma/rdma_netlink.h>
 #include <time.h>
+#include <net/if_arp.h>
 
 #include "list.h"
 #include "utils.h"
 #include "json_writer.h"
+#include <rdma/rdma_cma.h>
 
 #define pr_err(args...) fprintf(stderr, ##args)
 #define pr_out(args...) fprintf(stdout, ##args)

rdma/res.c +14 -1

index 62f5c54..1ef4f20 100644
@@ -16,9 +16,11 @@ static int res_help(struct rd *rd)
 {
 	pr_out("Usage: %s resource\n", rd->filename);
 	pr_out("          resource show [DEV]\n");
-	pr_out("          resource show [qp]\n");
+	pr_out("          resource show [qp|cm_id]\n");
 	pr_out("          resource show qp link [DEV/PORT]\n");
 	pr_out("          resource show qp link [DEV/PORT] [FILTER-NAME FILTER-VALUE]\n");
+	pr_out("          resource show cm_id link [DEV/PORT]\n");
+	pr_out("          resource show cm_id link [DEV/PORT] [FILTER-NAME FILTER-VALUE]\n");
 	return 0;
 }
 

@@ -433,6 +435,230 @@ static int res_qp_parse_cb(const struct nlmsghdr *nlh, void *data)
 	return MNL_CB_OK;
 }
 
+static void print_qp_type(struct rd *rd, uint32_t val)
+{
+	if (rd->json_output)
+		jsonw_string_field(rd->jw, "qp-type",
+				   qp_types_to_str(val));
+	else
+		pr_out("qp-type %s ", qp_types_to_str(val));
+}
+
+static const char *cm_id_state_to_str(uint8_t idx)
+{

rdma/res.c static int res_qp_parse_cb(const struct nlmsghdr *nlh, void *data) · line 453

Quoted 5 lines

rdma/res.c +5 -0

+	static const char * const cm_id_states_str[] = { "IDLE", "ADDR_QUERY",
+						      "ADDR_RESOLVED", "ROUTE_QUERY", "ROUTE_RESOLVED",
+						      "CONNECT", "DISCONNECT",
+						      "ADDR_BOUND", "LISTEN", "DEVICE_REMOVAL", "DESTROYING" };
+

In general lines should stay under 80 columns. There are a few exceptions to the rule (e.g., print strings), but most of the long lines you have in this patch need to conform.

Quoted 20 lines

rdma/res.c +16 -0

@@ -457,11 +683,41 @@ filters qp_valid_filters[MAX_NUMBER_OF_FILTERS] = {{ .name = "link",
 
 RES_FUNC(res_qp,	RDMA_NLDEV_CMD_RES_QP_GET, qp_valid_filters, false);
 
+static const struct
+filters cm_id_valid_filters[MAX_NUMBER_OF_FILTERS] = {{ .name = "link",
+						   .is_number = false },
+						   { .name = "lqpn",
+						   .is_number = true },
+						   { .name = "qp-type",
+						   .is_number = false },
+						   { .name = "state",
+						   .is_number = false },
+						   { .name = "ps",
+						   .is_number = false },
+						   { .name = "dev-type",
+						   .is_number = false },
+						   { .name = "transport-type",
+						   .is_number = false },
+						   { .name = "pid",

rdma/res.c filters qp_valid_filters[MAX_NUMBER_OF_FILTERS] = {{ .name = "link", · line 711

Quoted 10 lines

rdma/res.c +10 -0

+						   .is_number = true },
+						   { .name = "src-addr",
+						   .is_number = false },
+						   { .name = "src-port",
+						   .is_number = true },
+						   { .name = "dst-addr",
+						   .is_number = false },
+						   { .name = "dst-port",
+						   .is_number = true }};
+

The above would be more readable as

	static const
	struct filters cm_id_valid_filters[MAX_NUMBER_OF_FILTERS] = {
		{ .name = "link", .is_number = false },
		{ .name = "lqpn", .is_number = true },

...

Definitely do not split between struct and filters.

Sample output:

# rdma resource show cq
link cxgb4_0/- cqe 46 users 2 pid 30503 comm rping
link cxgb4_0/- cqe 46 users 2 pid 30498 comm rping
link mlx4_0/- cqe 63 users 2 pid 30494 comm rping
link mlx4_0/- cqe 63 users 2 pid 30489 comm rping
link mlx4_0/- cqe 1023 users 2 poll_ctx WORKQUEUE pid 0 comm [ib_core]

# rdma resource show cq pid 30489
link mlx4_0/- cqe 63 users 2 pid 30489 comm rping

Signed-off-by Steve Wise <[email protected]>

---
 rdma/res.c   | 136 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 rdma/utils.c |   5 +++
 2 files changed, 141 insertions(+)

Sample output:

Without CAP_NET_ADMIN:

$ rdma resource show mr mrlen 65536
link mlx4_0/- mrlen 65536 pid 0 comm [nvme_rdma]
link cxgb4_0/- mrlen 65536 pid 0 comm [nvme_rdma]

With CAP_NET_ADMIN:

# rdma resource show mr mrlen 65536
link mlx4_0/- rkey 0x12702 lkey 0x12702 iova 0x85724a000 mrlen 65536 pid 0 comm [nvme_rdma]
link cxgb4_0/- rkey 0x68fe4e9 lkey 0x68fe4e9 iova 0x835b91000 mrlen 65536 pid 0 comm [nvme_rdma]

Signed-off-by Steve Wise <[email protected]>

---
 include/json_writer.h |   2 +
 lib/json_writer.c     |  11 +++++
 rdma/res.c            | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++
 rdma/utils.c          |   6 +++
 4 files changed, 144 insertions(+)

Sample output:

Without CAP_NET_ADMIN capability:

link mlx4_0/- users 0 pid 0 comm [ib_srpt]
link mlx4_0/- users 0 pid 0 comm [ib_srp]
link mlx4_0/- users 1 pid 0 comm [ib_core]
link cxgb4_0/- users 0 pid 0 comm [ib_srp]

With CAP_NET_ADMIN capability:
link mlx4_0/- local_dma_lkey 0x8000 users 0 pid 0 comm [ib_srpt] link mlx4_0/- local_dma_lkey 0x8000 users 0 pid 0 comm [ib_srp] link mlx4_0/- local_dma_lkey 0x8000 users 1 pid 0 comm [ib_core] link cxgb4_0/- local_dma_lkey 0x0 users 0 pid 0 comm [ib_srp]

Signed-off-by Steve Wise <[email protected]>

---
 rdma/res.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)

-----Original Message-----
From: [email protected] [mailto:linux-rdma- [email protected]] On Behalf Of Steve Wise
Sent: Friday, March 02, 2018 1:56 PM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]
Subject: [PATCH v2 iproute2-next 0/6] cm_id, cq, mr, and pd resource

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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.

Quoted 5 lines

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?

Quoted 5 lines · 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.

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?

Quoted 10 lines · David Ahern

Quoted 5 lines · 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.

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?

Quoted 18 lines · Leon Romanovsky

Quoted 10 lines · David Ahern

Quoted 5 lines · 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.

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.

Quoted 4 lines

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.

Quoted 24 lines · David Ahern

Quoted 22 lines · Leon Romanovsky

Quoted 10 lines · David Ahern

Quoted 5 lines · 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.

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?

Quoted 2 lines

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.

Quoted 28 lines · Doug Ledford

Quoted 26 lines · David Ahern

Quoted 14 lines · Leon Romanovsky

Quoted 10 lines · David Ahern

Quoted 5 lines · 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.

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,

Quoted 8 lines

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?

Quoted 4 lines

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?

Quoted 29 lines · David Ahern

Quoted 28 lines · Doug Ledford

Quoted 26 lines · David Ahern

Quoted 14 lines · Leon Romanovsky

Quoted 10 lines · David Ahern

Quoted 5 lines · 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.

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,

Quoted 8 lines

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?

Quoted 7 lines

Quoted 4 lines

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.

Quoted 32 lines · Doug Ledford

Quoted 23 lines · David Ahern

Quoted 22 lines · Doug Ledford

Quoted 21 lines · David Ahern

Quoted 20 lines · Leon Romanovsky

Quoted 9 lines · David Ahern

Quoted 5 lines · 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.

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?

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

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?

Quoted 8 lines

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.

Quoted 2 lines

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?

Quoted 18 lines · Leon Romanovsky

Quoted 10 lines · David Ahern

Quoted 5 lines · 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.

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.

Quoted 4 lines

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.

Quoted 2 lines · Jason Gunthorpe

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?

Quoted 6 lines · David Ahern

Quoted 2 lines · Jason Gunthorpe

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

Quoted 18 lines · Jason Gunthorpe

Quoted 6 lines · David Ahern

Quoted 2 lines · Jason Gunthorpe

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.

Quoted 2 lines

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.