Skip to contentSkip to conversation

Refactor rdma_cm query GID API

PATCH In review Leon Romanovsky 4 participants 13 messages Jan 9, 2018 – Jan 18, 2018 9 messages not in the archive

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

cover Refactor rdma_cm query GID API

Hi,

The following patchset continues the previous refactoring series targeted for rdma-next.

The goal of the folliwing patches is to simplify and provide consistient interface to query GIDs from rdma_cm.

Thanks

Cc Santosh Shilimkar <[email protected]>

Parav Pandit (3):
RDMA/core: Remove RoCE support from rdma_addr_get_sgid() RDMA/cma: Introduce API to read GIDs for multiple transports
RDMA: Use rdma_cm API to query GID

 drivers/infiniband/core/cma.c  | 18 ++++++++++++++++
 drivers/infiniband/core/ucma.c |  8 +++----
 include/rdma/ib_addr.h         | 49 +++++++++++++++++++-----------------------
 include/rdma/rdma_cm.h         | 19 ++++++++++++++++
 net/rds/ib.c                   |  6 ++----
 5 files changed, 65 insertions(+), 35 deletions(-)

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

A message that is not in the archive (sent off-list or not yet received): 20180109111058.29534-1-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org

#2 lore raw

PATCH 1/3 RDMA/core: Remove RoCE support from rdma_addr_get_sgid()

From: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>

There are number of issues with RoCE support in rdma_addr_get_sgid() call:

1. With IP based GIDs, SGID derived using iboe_addr_get_sgid() was not used in connection establishment process. SGID was always derived using ip2gid().

2. It returns the first IP address of the netdevice, while netdevice can have multiple IP addresses and connection could have been established using non first IP address.

3. It returns SGID based on IPv4 address. It doesn't cover IPv6 addresses.

4. As the comment of rdma_dev_addr src_dev_addr and dst_dev_addr suggest, such members of rdma_dev_addr stores the mac address. Therefore it is not the best place to store the RoCE GIDs. RoCE GIDs are derived from the IP addresses and they are already available in cm_id->route->addr.***_addr.

It was only used to return SGID to rds/ib.c and ucma.c modules, where it returned incorrect SGID in above matching conditions.

Therefore code is simplified to not support RoCE.

---
 include/rdma/ib_addr.h | 35 +++++++++--------------------------
 1 file changed, 9 insertions(+), 26 deletions(-)
include/rdma/ib_addr.h +9 -26
index dc0b642e0175..fa809a7b48e7 100644
@@ -197,34 +197,17 @@ static inline void rdma_gid2ip(struct sockaddr *out, const union ib_gid *gid)
 	}
 }
 
-static inline void iboe_addr_get_sgid(struct rdma_dev_addr *dev_addr,
+/*
+ * rdma_get/set_sgid/dgid() APIs are applicable to IB and iWARP.
+ * They are not applicable to RoCE, because RoCE GIDs are derived
+ * from the IP addresses.
+ */
+static inline void rdma_addr_get_sgid(struct rdma_dev_addr *dev_addr,
 				      union ib_gid *gid)
 {
-	struct net_device *dev;
-	struct in_device *ip4;
-
-	dev = dev_get_by_index(&init_net, dev_addr->bound_dev_if);
-	if (dev) {
-		ip4 = in_dev_get(dev);
-		if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address)
-			ipv6_addr_set_v4mapped(ip4->ifa_list->ifa_address,
-					       (struct in6_addr *)gid);
-
-		if (ip4)
-			in_dev_put(ip4);
-
-		dev_put(dev);
-	}
-}
-
-static inline void rdma_addr_get_sgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
-{
-	if (dev_addr->transport == RDMA_TRANSPORT_IB &&
-	    dev_addr->dev_type != ARPHRD_INFINIBAND)
-		iboe_addr_get_sgid(dev_addr, gid);
-	else
-		memcpy(gid, dev_addr->src_dev_addr +
-		       rdma_addr_gid_offset(dev_addr), sizeof *gid);
+	memcpy(gid,
+	       dev_addr->src_dev_addr + rdma_addr_gid_offset(dev_addr),
+	       sizeof(*gid));
 }
 
 static inline void rdma_addr_set_sgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
Signature · 6 lines
2.15.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

A message that is not in the archive (sent off-list or not yet received): 20180109111058.29534-2-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org

#4 lore raw

Re: [PATCH rdma-next 1/3] RDMA/core: Remove RoCE support from rdma_addr_get_sgid()

Quoted 14 lines · Leon Romanovsky

From: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>

There are number of issues with RoCE support in rdma_addr_get_sgid() call:

1. With IP based GIDs, SGID derived using iboe_addr_get_sgid() was not used in connection establishment process. SGID was always derived using ip2gid().

2. It returns the first IP address of the netdevice, while netdevice can have multiple IP addresses and connection could have been established using non first IP address.

3. It returns SGID based on IPv4 address. It doesn't cover IPv6 addresses.

Quoted 7 lines

4. As the comment of rdma_dev_addr src_dev_addr and dst_dev_addr suggest, such members of rdma_dev_addr stores the mac address. Therefore it is not the best place to store the RoCE GIDs. RoCE GIDs are derived from the IP addresses and they are already available in cm_id->route->addr.***_addr.

It was only used to return SGID to rds/ib.c and ucma.c modules, where it returned incorrect SGID in above matching conditions.

Yes, but if those conditions were not matched it did something useful and now what happens?

All the callers in ucma.c are returning the result to userspace, so this patch looks like it is changing the uapi in some way?

Can you define what the SGID/DGID should be in the rdma CM uapi when working with rocee?

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

A message that is not in the archive (sent off-list or not yet received): 20180115220741.GA18489-uk2M96/[email protected]

#6 lore raw

RE: [PATCH rdma-next 1/3] RDMA/core: Remove RoCE support from rdma_addr_get_sgid()

Quoted 33 lines

-----Original Message-----
From: Jason Gunthorpe [mailto:jgg-uk2M96/[email protected]]
Sent: Monday, January 15, 2018 4:08 PM
To: Leon Romanovsky <[email protected]>
Cc: Doug Ledford <[email protected]>; RDMA mailing list <linux- [email protected]>; Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/[email protected]>; Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>
Subject: Re: [PATCH rdma-next 1/3] RDMA/core: Remove RoCE support from
rdma_addr_get_sgid()

Quoted 20 lines · Leon Romanovsky

From: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>

There are number of issues with RoCE support in rdma_addr_get_sgid() call:

1. With IP based GIDs, SGID derived using iboe_addr_get_sgid() was not used in connection establishment process. SGID was always derived using ip2gid().

2. It returns the first IP address of the netdevice, while netdevice can have multiple IP addresses and connection could have been established using non first IP address.

3. It returns SGID based on IPv4 address. It doesn't cover IPv6 addresses.

4. As the comment of rdma_dev_addr src_dev_addr and dst_dev_addr suggest, such members of rdma_dev_addr stores the mac address. Therefore it is not the best place to store the RoCE GIDs. RoCE GIDs are derived from the IP addresses and they are already available in cm_id- route->addr.***_addr.

Quoted 5 lines
Quoted 2 lines

It was only used to return SGID to rds/ib.c and ucma.c modules, where it returned incorrect SGID in above matching conditions.

Yes, but if those conditions were not matched it did something useful and now what happens?

Now it returns correct SGID in matched and unmatched cases.

Quoted 3 lines

All the callers in ucma.c are returning the result to userspace, so this patch looks like it is changing the uapi in some way?

No. It doesn't change uapi. It fixes cases by returning appropriate GID.

Quoted 4 lines

Can you define what the SGID/DGID should be in the rdma CM uapi when working with rocee?

It is the GIDs derived from the IP address using ip2gid() conversion. --
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

A message that is not in the archive (sent off-list or not yet received): VI1PR0502MB300827C3710085B7D3C3A924D1EB0-o1MPJYiShExKsLr+rGaxW8DSnupUy6xnnBOFsp37pqbUKgpGm//BTAC/[email protected]

#8 lore raw

Re: [PATCH rdma-next 1/3] RDMA/core: Remove RoCE support from rdma_addr_get_sgid()

Quoted 4 lines · Parav Pandit
Quoted 3 lines

Can you define what the SGID/DGID should be in the rdma CM uapi when working with rocee?

It is the GIDs derived from the IP address using ip2gid() conversion.

So then why is it OK for this patch to start returning dev_addr->src_dev_addr ?

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

A message that is not in the archive (sent off-list or not yet received): 20180115224742.GD2206-uk2M96/[email protected]

#10 lore raw

RE: [PATCH rdma-next 1/3] RDMA/core: Remove RoCE support from rdma_addr_get_sgid()

Quoted 12 lines

-----Original Message-----
From: Jason Gunthorpe [mailto:jgg-uk2M96/[email protected]]
Sent: Monday, January 15, 2018 4:48 PM
To: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>
Cc: Leon Romanovsky <[email protected]>; Doug Ledford <[email protected]>; RDMA mailing list <[email protected]>; Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/[email protected]>
Subject: Re: [PATCH rdma-next 1/3] RDMA/core: Remove RoCE support from
rdma_addr_get_sgid()

Quoted 9 lines
Quoted 4 lines · Parav Pandit
Quoted 3 lines

Can you define what the SGID/DGID should be in the rdma CM uapi when working with rocee?

It is the GIDs derived from the IP address using ip2gid() conversion.

So then why is it OK for this patch to start returning dev_addr->src_dev_addr ?

It is not ok for RoCE. Therefore as the subject line says, it is no longer supported for RoCE. For other transports the code is unchanged. It continues to report src_dev_addr. For example, for IB transport GIDs are not derived IP address.
--
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

#11 lore raw

PATCH 2/3 RDMA/cma: Introduce API to read GIDs for multiple transports

In reply to a message not in the archive

From: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>

This patch introduces an API that allows legacy applications to query GIDs for a rdma_cm_id which is used during connection establishment.

GIDs are stored and created differently for IB, RoCE and iWARP transports. Therefore rdma_read_gids() returns GID for all the transports hiding such internal details to caller. It is usable for client side and server side connections.

The rdma_read_gids() should not be used by any new ULPs.

---
 drivers/infiniband/core/cma.c | 18 ++++++++++++++++++
 include/rdma/ib_addr.h        | 16 ++++++++++++++--
 include/rdma/rdma_cm.h        | 19 +++++++++++++++++++
 3 files changed, 51 insertions(+), 2 deletions(-)
drivers/infiniband/core/cma.c +18 -0
index f4c6c2cbc585..169d3a3bbf71 100644
@@ -2037,6 +2037,24 @@ __be64 rdma_get_service_id(struct rdma_cm_id *id, struct sockaddr *addr)
 }
 EXPORT_SYMBOL(rdma_get_service_id);
 
+void rdma_read_gids(struct rdma_cm_id *cm_id, union ib_gid *sgid,
+		    union ib_gid *dgid)
+{
+	struct rdma_addr *addr = &cm_id->route.addr;
+
+	if (!cm_id->device)
+		return;
+
+	if (rdma_protocol_roce(cm_id->device, cm_id->port_num)) {
+		rdma_ip2gid((struct sockaddr *)&addr->src_addr, sgid);
+		rdma_ip2gid((struct sockaddr *)&addr->dst_addr, dgid);
+	} else {
+		rdma_addr_get_sgid(&addr->dev_addr, sgid);
+		rdma_addr_get_dgid(&addr->dev_addr, dgid);
+	}
+}
+EXPORT_SYMBOL(rdma_read_gids);
+
 static int cma_iw_handler(struct iw_cm_id *iw_id, struct iw_cm_event *iw_event)
 {
 	struct rdma_id_private *id_priv = iw_id->context;
include/rdma/ib_addr.h +14 -2
index fa809a7b48e7..edb1cdf2a892 100644
@@ -165,6 +165,9 @@ static inline u16 rdma_vlan_dev_vlan_id(const struct net_device *dev)
 
 static inline int rdma_ip2gid(struct sockaddr *addr, union ib_gid *gid)
 {
+	if (!gid)
+		return 0;
+
 	switch (addr->sa_family) {
 	case AF_INET:
 		ipv6_addr_set_v4mapped(((struct sockaddr_in *)
@@ -205,6 +208,9 @@ static inline void rdma_gid2ip(struct sockaddr *out, const union ib_gid *gid)
 static inline void rdma_addr_get_sgid(struct rdma_dev_addr *dev_addr,
 				      union ib_gid *gid)
 {
+	if (!gid)
+		return;
+
 	memcpy(gid,
 	       dev_addr->src_dev_addr + rdma_addr_gid_offset(dev_addr),
 	       sizeof(*gid));
@@ -215,9 +221,15 @@ static inline void rdma_addr_set_sgid(struct rdma_dev_addr *dev_addr, union ib_g
 	memcpy(dev_addr->src_dev_addr + rdma_addr_gid_offset(dev_addr), gid, sizeof *gid);
 }
 
-static inline void rdma_addr_get_dgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
+static inline void rdma_addr_get_dgid(struct rdma_dev_addr *dev_addr,
+				      union ib_gid *gid)
 {
-	memcpy(gid, dev_addr->dst_dev_addr + rdma_addr_gid_offset(dev_addr), sizeof *gid);
+	if (!gid)
+		return;
+
+	memcpy(gid,
+	       dev_addr->dst_dev_addr + rdma_addr_gid_offset(dev_addr),
+	       sizeof(*gid));
 }
 
 static inline void rdma_addr_set_dgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
include/rdma/rdma_cm.h +19 -0
index 3d2eed3c4e75..6538a5cc27b6 100644
@@ -413,4 +413,23 @@ bool rdma_is_consumer_reject(struct rdma_cm_id *id, int reason);
 const void *rdma_consumer_reject_data(struct rdma_cm_id *id,
 				      struct rdma_cm_event *ev, u8 *data_len);
 
+/**
+ * rdma_read_gids - Return the SGID and DGID used for establishing
+ *                  connection. This can be used after rdma_resolve_addr()
+ *                  on client side. This can be use on new connection
+ *                  on server side. This is applicable to IB, RoCE, iWarp.
+ *                  If cm_id is not bound yet to the RDMA device, it doesn't
+ *                  copy and SGID or DGID to the given pointers.
+ * @id: Communication identifier whose GIDs are queried.
+ * @sgid: Pointer to SGID where SGID will be returned. It is optional.
+ * @dgid: Pointer to DGID where DGID will be returned. It is optional.
+ * Note: This API should not be used by any new ULPs or new code.
+ * Instead, users interested in querying GIDs should refer to path record
+ * of the rdma_cm_id to query the GIDs.
+ * This API is provided for compatibility for existing users.
+ */
+
+void rdma_read_gids(struct rdma_cm_id *cm_id, union ib_gid *sgid,
+		    union ib_gid *dgid);
+
 #endif /* RDMA_CM_H */
Signature · 6 lines
2.15.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

A message that is not in the archive (sent off-list or not yet received): 20180109111058.29534-3-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org

#13 lore raw

Re: [PATCH rdma-next 2/3] RDMA/cma: Introduce API to read GIDs for multiple transports

Quoted 11 lines · Leon Romanovsky

From: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>

This patch introduces an API that allows legacy applications to query GIDs for a rdma_cm_id which is used during connection establishment.

GIDs are stored and created differently for IB, RoCE and iWARP transports. Therefore rdma_read_gids() returns GID for all the transports hiding such internal details to caller. It is usable for client side and server side connections.

The rdma_read_gids() should not be used by any new ULPs.

This is weird statement. Why can't we change the few callers to do whatever is correct now?

drivers/infiniband/core/cma.c __be64 rdma_get_service_id(struct rdma_cm_id *id, struct sockaddr *addr) · line 2046

Quoted 7 lines
drivers/infiniband/core/cma.c +7 -0
+void rdma_read_gids(struct rdma_cm_id *cm_id, union ib_gid *sgid,
+		    union ib_gid *dgid)
+{
+	struct rdma_addr *addr = &cm_id->route.addr;
+
+	if (!cm_id->device)
+		return;

Nope. I looked at only one caller and saw this return leaks uninited kernel stack memory to userspace. Probably best to zero the sgid/dgid in the error case??

Quoted 14 lines
include/rdma/ib_addr.h +4 -0
index fa809a7b48e7..edb1cdf2a892 100644
+++ b/include/rdma/ib_addr.h
@@ -165,6 +165,9 @@ static inline u16 rdma_vlan_dev_vlan_id(const struct net_device *dev)
 
 static inline int rdma_ip2gid(struct sockaddr *addr, union ib_gid *gid)
 {
+	if (!gid)
+		return 0;
+
 	switch (addr->sa_family) {
 	case AF_INET:
 		ipv6_addr_set_v4mapped(((struct sockaddr_in *)

include/rdma/ib_addr.h static inline void rdma_gid2ip(struct sockaddr *out, const union ib_gid *gid) · line 212

Quoted 5 lines
include/rdma/ib_addr.h +2 -0
@@ -205,6 +208,9 @@ static inline void rdma_gid2ip(struct sockaddr *out, const union ib_gid *gid)
 static inline void rdma_addr_get_sgid(struct rdma_dev_addr *dev_addr,
 				      union ib_gid *gid)
 {
+	if (!gid)
+		return;

I think it would be clearer to put this test in the rdma_read_gids. It makes no sense to have a function with one output where the output is optional. Particularly when it is inlined..

And the prior patch makes a bit more sense after looking here, but the series seems in the wrong order -> the patch to break rdma_addr_get_sgid should go after the only rocee code path in ucma is switched to use rdma_read_gids which hopefully does something similar to what it did before?

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

A message that is not in the archive (sent off-list or not yet received): 20180115222215.GA18795-uk2M96/[email protected]

#15 lore raw

RE: [PATCH rdma-next 2/3] RDMA/cma: Introduce API to read GIDs for multiple transports

Quoted 23 lines

-----Original Message-----
From: Jason Gunthorpe [mailto:jgg-uk2M96/[email protected]]
Sent: Monday, January 15, 2018 4:22 PM
To: Leon Romanovsky <[email protected]>
Cc: Doug Ledford <[email protected]>; RDMA mailing list <linux- [email protected]>; Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/[email protected]>; Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>
Subject: Re: [PATCH rdma-next 2/3] RDMA/cma: Introduce API to read GIDs for
multiple transports

Quoted 10 lines · Leon Romanovsky

From: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>

This patch introduces an API that allows legacy applications to query GIDs for a rdma_cm_id which is used during connection establishment.

GIDs are stored and created differently for IB, RoCE and iWARP transports. Therefore rdma_read_gids() returns GID for all the transports hiding such internal details to caller. It is usable for client side and server side connections.

Quoted 5 lines
Quoted 1 line

The rdma_read_gids() should not be used by any new ULPs.

This is weird statement. Why can't we change the few callers to do whatever is correct now?

Because rdmacm doesn't expose the GIDs. Rdmacm works on IP addresses. It uses GIDs to internally do the binding and attachment to right ib device. But GIDs are not UAPIs from rdmacm perspective.
Therefore it should not be exposed for any new ULPs/users.

Quoted 10 lines

drivers/infiniband/core/cma.c __be64 rdma_get_service_id(struct rdma_cm_id *id, struct sockaddr *addr) · line 2046

Quoted 7 lines
drivers/infiniband/core/cma.c +7 -0
+void rdma_read_gids(struct rdma_cm_id *cm_id, union ib_gid *sgid,
+		    union ib_gid *dgid)
+{
+	struct rdma_addr *addr = &cm_id->route.addr;
+
+	if (!cm_id->device)
+		return;

Nope. I looked at only one caller and saw this return leaks uninited kernel stack memory to userspace. Probably best to zero the sgid/dgid in the error case??

Ok. That can be done.

Quoted 19 lines
Quoted 14 lines
include/rdma/ib_addr.h index renamed from include/rdma/ib_addr.h +0 -0

fa809a7b48e7..edb1cdf2a892 100644
+++ b/include/rdma/ib_addr.h

include/rdma/ib_addr.h index renamed from include/rdma/ib_addr.h +3 -0
@@ -165,6 +165,9 @@ static inline u16 rdma_vlan_dev_vlan_id(const
 struct net_device *dev)
 
 static inline int rdma_ip2gid(struct sockaddr *addr, union ib_gid
 *gid)  {
+	if (!gid)
+		return 0;
+
 	switch (addr->sa_family) {
 	case AF_INET:
Quoted 1 line

ipv6_addr_set_v4mapped(((struct sockaddr_in *) @@ -205,6

+208,9 @@

Quoted 2 lines

static inline void rdma_gid2ip(struct sockaddr *out, const union ib_gid *gid) static inline void rdma_addr_get_sgid(struct rdma_dev_addr

*dev_addr,

Quoted 8 lines

include/rdma/ib_addr.h index

Quoted 4 lines
include/rdma/ib_addr.h index renamed from include/rdma/ib_addr.h +2 -0
 				      union ib_gid *gid)
 {
+	if (!gid)
+		return;

I think it would be clearer to put this test in the rdma_read_gids. It makes no sense to have a function with one output where the output is optional. Particularly when it is inlined..

Ok. Make sense to me.

Quoted 3 lines

And the prior patch makes a bit more sense after looking here, but the series seems in the wrong order -> the patch to break rdma_addr_get_sgid should go

rdma_addr_get_sgid() worked only in very limited case.
Since all patches are in same series, I don't see order breaks anything. But changing order is fine in revised series.

Quoted 3 lines

after the only rocee code path in ucma is switched to use rdma_read_gids which hopefully does something similar to what it did before?

Yes, it returns IP based GID for multiple missing cases and previous simple case too.

Quoted 1 line

Jason

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

A message that is not in the archive (sent off-list or not yet received): VI1PR0502MB30082F945F147FF434835DF3D1EB0-o1MPJYiShExKsLr+rGaxW8DSnupUy6xnnBOFsp37pqbUKgpGm//BTAC/[email protected]

#17 lore raw

Re: [PATCH rdma-next 2/3] RDMA/cma: Introduce API to read GIDs for multiple transports

Quoted 6 lines · Parav Pandit
Quoted 2 lines

And the prior patch makes a bit more sense after looking here, but the series seems in the wrong order -> the patch to break rdma_addr_get_sgid should go

rdma_addr_get_sgid() worked only in very limited case. Since all patches are in same series, I don't see order breaks anything. But changing order is fine in revised series.

When you order the patches in a series you are trying to tell a story to the reviewer. It isn't just a random collection of related patches.

Here the story is fixing the few places that are hard wired to use GIDs to have sane GID information for RoCE.

Every patch should advance that story withou outgoing backwards. In this case the first patch totally breaks the GIDs in RoCE which breaks the understandability of the story - if you had put this patch at the end of the list and said:

Now that all RoCE users of rdma_addr_get_sgid() call rdma_read_gids() we can remove the sketchy RoCE specific support from rdma_addr_get_sgid()

Then the entire story makes a lot more sense, and the patch becomes a conclusion, not a confusing starting point.

This also aide bisect-ability - we don't want to see patches break working functionality in the middle of a series because 'git bisect' does not know about series boundaries.

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

#18 lore raw

Re: [PATCH rdma-next 2/3] RDMA/cma: Introduce API to read GIDs for multiple transports

In reply to a message not in the archive
Quoted 43 lines · Jason Gunthorpe
Quoted 11 lines · Leon Romanovsky

From: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>

This patch introduces an API that allows legacy applications to query GIDs for a rdma_cm_id which is used during connection establishment.

GIDs are stored and created differently for IB, RoCE and iWARP transports. Therefore rdma_read_gids() returns GID for all the transports hiding such internal details to caller. It is usable for client side and server side connections.

The rdma_read_gids() should not be used by any new ULPs.

This is weird statement. Why can't we change the few callers to do whatever is correct now?

drivers/infiniband/core/cma.c __be64 rdma_get_service_id(struct rdma_cm_id *id, struct sockaddr *addr) · line 2046

Quoted 7 lines
drivers/infiniband/core/cma.c +7 -0
+void rdma_read_gids(struct rdma_cm_id *cm_id, union ib_gid *sgid,
+		    union ib_gid *dgid)
+{
+	struct rdma_addr *addr = &cm_id->route.addr;
+
+	if (!cm_id->device)
+		return;

Nope. I looked at only one caller and saw this return leaks uninited kernel stack memory to userspace. Probably best to zero the sgid/dgid in the error case??

Quoted 15 lines
include/rdma/ib_addr.h +4 -0
index fa809a7b48e7..edb1cdf2a892 100644
+++ b/include/rdma/ib_addr.h
@@ -165,6 +165,9 @@ static inline u16 rdma_vlan_dev_vlan_id(const struct net_device *dev)
 
 static inline int rdma_ip2gid(struct sockaddr *addr, union ib_gid *gid)
 {
+	if (!gid)
+		return 0;
+
 	switch (addr->sa_family) {
 	case AF_INET:
 		ipv6_addr_set_v4mapped(((struct sockaddr_in *)
@@ -205,6 +208,9 @@ static inline void rdma_gid2ip(struct sockaddr *out, const union ib_gid *gid)
 static inline void rdma_addr_get_sgid(struct rdma_dev_addr *dev_addr,
Quoted 8 lines

include/rdma/ib_addr.h static inline void rdma_gid2ip(struct sockaddr *out, const union ib_gid *gid) · line 212

Quoted 4 lines
include/rdma/ib_addr.h +2 -0
 				      union ib_gid *gid)
 {
+	if (!gid)
+		return;

I think it would be clearer to put this test in the rdma_read_gids. It makes no sense to have a function with one output where the output is optional. Particularly when it is inlined..

Actually, I changed Parav's original code in this patch to be the construction as you commented now. For me, rdma_read_gids() looked so ugly with sgid, dgid checks so i didn't want to show it to anybody, you will see it in v1.

Quoted 8 lines

And the prior patch makes a bit more sense after looking here, but the series seems in the wrong order -> the patch to break rdma_addr_get_sgid should go after the only rocee code path in ucma is switched to use rdma_read_gids which hopefully does something similar to what it did before?

Jason

#19 lore raw

PATCH 3/3 RDMA: Use rdma_cm API to query GID

In reply to a message not in the archive

From: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>

Make use of rdma_read_gids() function to read SGID and DGID which returns correct GIDs for all transports.

---
 drivers/infiniband/core/ucma.c | 8 ++++----
 net/rds/ib.c                   | 6 ++----
 2 files changed, 6 insertions(+), 8 deletions(-)
drivers/infiniband/core/ucma.c +4 -4
index 29a81e6cfc96..8699b3a1d464 100644
@@ -944,8 +944,8 @@ static ssize_t ucma_query_gid(struct ucma_context *ctx,
 	} else {
 		addr->sib_family = AF_IB;
 		addr->sib_pkey = (__force __be16) resp.pkey;
-		rdma_addr_get_sgid(&ctx->cm_id->route.addr.dev_addr,
-				   (union ib_gid *) &addr->sib_addr);
+		rdma_read_gids(ctx->cm_id, (union ib_gid *)&addr->sib_addr,
+			       NULL);
 		addr->sib_sid = rdma_get_service_id(ctx->cm_id, (struct sockaddr *)
 						    &ctx->cm_id->route.addr.src_addr);
 	}
@@ -957,8 +957,8 @@ static ssize_t ucma_query_gid(struct ucma_context *ctx,
 	} else {
 		addr->sib_family = AF_IB;
 		addr->sib_pkey = (__force __be16) resp.pkey;
-		rdma_addr_get_dgid(&ctx->cm_id->route.addr.dev_addr,
-				   (union ib_gid *) &addr->sib_addr);
+		rdma_read_gids(ctx->cm_id, NULL,
+			       (union ib_gid *)&addr->sib_addr);
 		addr->sib_sid = rdma_get_service_id(ctx->cm_id, (struct sockaddr *)
 						    &ctx->cm_id->route.addr.dst_addr);
 	}
net/rds/ib.c +2 -4
index 36dd2099048a..b2a5067b4afe 100644
@@ -301,13 +301,11 @@ static int rds_ib_conn_info_visitor(struct rds_connection *conn,
 	memset(&iinfo->dst_gid, 0, sizeof(iinfo->dst_gid));
 	if (rds_conn_state(conn) == RDS_CONN_UP) {
 		struct rds_ib_device *rds_ibdev;
-		struct rdma_dev_addr *dev_addr;
 
 		ic = conn->c_transport_data;
-		dev_addr = &ic->i_cm_id->route.addr.dev_addr;
 
-		rdma_addr_get_sgid(dev_addr, (union ib_gid *) &iinfo->src_gid);
-		rdma_addr_get_dgid(dev_addr, (union ib_gid *) &iinfo->dst_gid);
+		rdma_read_gids(ic->i_cm_id, (union ib_gid *)&iinfo->src_gid,
+			       (union ib_gid *)&iinfo->dst_gid);
 
 		rds_ibdev = ic->rds_ibdev;
 		iinfo->max_send_wr = ic->i_send_ring.w_nr;
Signature · 6 lines
2.15.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

A message that is not in the archive (sent off-list or not yet received): 20180109111058.29534-4-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org

#21 lore raw

Re: [PATCH rdma-next 3/3] RDMA: Use rdma_cm API to query GID

Quoted 5 lines · Leon Romanovsky

From: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>

Make use of rdma_read_gids() function to read SGID and DGID which returns correct GIDs for all transports.

Quoted 8 lines
---
  drivers/infiniband/core/ucma.c | 8 ++++----
  net/rds/ib.c                   | 6 ++----
  2 files changed, 6 insertions(+), 8 deletions(-)

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