2020-07-19 15:25:21 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */
|
2006-06-18 11:37:28 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2005 Voltaire Inc. All rights reserved.
|
|
|
|
* Copyright (c) 2005 Intel Corporation. All rights reserved.
|
|
|
|
*/
|
|
|
|
|
2020-07-19 15:25:21 +08:00
|
|
|
#ifndef IB_ADDR_H
|
2006-06-18 11:37:28 +08:00
|
|
|
#define IB_ADDR_H
|
|
|
|
|
2020-11-21 06:50:52 +08:00
|
|
|
#include <linux/ethtool.h>
|
2006-06-18 11:37:28 +08:00
|
|
|
#include <linux/in.h>
|
|
|
|
#include <linux/in6.h>
|
2009-11-20 04:57:18 +08:00
|
|
|
#include <linux/if_arp.h>
|
2006-06-18 11:37:28 +08:00
|
|
|
#include <linux/netdevice.h>
|
2013-12-13 00:03:12 +08:00
|
|
|
#include <linux/inetdevice.h>
|
2006-06-18 11:37:28 +08:00
|
|
|
#include <linux/socket.h>
|
2010-08-26 22:18:59 +08:00
|
|
|
#include <linux/if_vlan.h>
|
2013-12-13 00:03:12 +08:00
|
|
|
#include <net/ipv6.h>
|
|
|
|
#include <net/if_inet6.h>
|
|
|
|
#include <net/ip.h>
|
2006-06-18 11:37:28 +08:00
|
|
|
#include <rdma/ib_verbs.h>
|
2010-10-14 03:26:51 +08:00
|
|
|
#include <rdma/ib_pack.h>
|
2015-10-22 20:20:08 +08:00
|
|
|
#include <net/net_namespace.h>
|
2006-06-18 11:37:28 +08:00
|
|
|
|
2015-10-22 20:20:08 +08:00
|
|
|
/**
|
|
|
|
* struct rdma_dev_addr - Contains resolved RDMA hardware addresses
|
|
|
|
* @src_dev_addr: Source MAC address.
|
|
|
|
* @dst_dev_addr: Destination MAC address.
|
|
|
|
* @broadcast: Broadcast address of the device.
|
|
|
|
* @dev_type: The interface hardware type of the device.
|
|
|
|
* @bound_dev_if: An optional device interface index.
|
|
|
|
* @transport: The transport type used.
|
|
|
|
* @net: Network namespace containing the bound_dev_if net_dev.
|
2018-06-19 15:59:17 +08:00
|
|
|
* @sgid_attr: GID attribute to use for identified SGID
|
2015-10-22 20:20:08 +08:00
|
|
|
*/
|
2006-06-18 11:37:28 +08:00
|
|
|
struct rdma_dev_addr {
|
|
|
|
unsigned char src_dev_addr[MAX_ADDR_LEN];
|
|
|
|
unsigned char dst_dev_addr[MAX_ADDR_LEN];
|
|
|
|
unsigned char broadcast[MAX_ADDR_LEN];
|
2009-11-20 04:57:18 +08:00
|
|
|
unsigned short dev_type;
|
2009-11-20 04:55:22 +08:00
|
|
|
int bound_dev_if;
|
2010-10-14 03:26:51 +08:00
|
|
|
enum rdma_transport_type transport;
|
2015-10-22 20:20:08 +08:00
|
|
|
struct net *net;
|
2018-06-19 15:59:17 +08:00
|
|
|
const struct ib_gid_attr *sgid_attr;
|
2015-12-23 20:56:51 +08:00
|
|
|
enum rdma_network_type network;
|
2016-01-04 16:49:54 +08:00
|
|
|
int hoplimit;
|
2006-06-18 11:37:28 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rdma_translate_ip - Translate a local IP address to an RDMA hardware
|
|
|
|
* address.
|
2015-10-22 20:20:08 +08:00
|
|
|
*
|
|
|
|
* The dev_addr->net field must be initialized.
|
2006-06-18 11:37:28 +08:00
|
|
|
*/
|
2015-12-23 20:56:53 +08:00
|
|
|
int rdma_translate_ip(const struct sockaddr *addr,
|
2017-11-14 20:52:10 +08:00
|
|
|
struct rdma_dev_addr *dev_addr);
|
2006-06-18 11:37:28 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* rdma_resolve_ip - Resolve source and destination IP addresses to
|
|
|
|
* RDMA hardware addresses.
|
|
|
|
* @src_addr: An optional source address to use in the resolution. If a
|
|
|
|
* source address is not provided, a usable address will be returned via
|
|
|
|
* the callback.
|
|
|
|
* @dst_addr: The destination address to resolve.
|
|
|
|
* @addr: A reference to a data location that will receive the resolved
|
|
|
|
* addresses. The data location must remain valid until the callback has
|
2015-10-22 20:20:08 +08:00
|
|
|
* been invoked. The net field of the addr struct must be valid.
|
2006-06-18 11:37:28 +08:00
|
|
|
* @timeout_ms: Amount of time to wait for the address resolution to complete.
|
|
|
|
* @callback: Call invoked once address resolution has completed, timed out,
|
|
|
|
* or been canceled. A status of 0 indicates success.
|
2018-09-05 17:54:26 +08:00
|
|
|
* @resolve_by_gid_attr: Resolve the ip based on the GID attribute from
|
|
|
|
* rdma_dev_addr.
|
2006-06-18 11:37:28 +08:00
|
|
|
* @context: User-specified context associated with the call.
|
|
|
|
*/
|
2018-07-29 16:53:10 +08:00
|
|
|
int rdma_resolve_ip(struct sockaddr *src_addr, const struct sockaddr *dst_addr,
|
2018-10-11 22:30:05 +08:00
|
|
|
struct rdma_dev_addr *addr, unsigned long timeout_ms,
|
2006-06-18 11:37:28 +08:00
|
|
|
void (*callback)(int status, struct sockaddr *src_addr,
|
|
|
|
struct rdma_dev_addr *addr, void *context),
|
2018-10-11 22:30:04 +08:00
|
|
|
bool resolve_by_gid_attr, void *context);
|
2006-06-18 11:37:28 +08:00
|
|
|
|
|
|
|
void rdma_addr_cancel(struct rdma_dev_addr *addr);
|
|
|
|
|
2018-07-29 16:53:10 +08:00
|
|
|
int rdma_addr_size(const struct sockaddr *addr);
|
2018-03-29 02:27:22 +08:00
|
|
|
int rdma_addr_size_in6(struct sockaddr_in6 *addr);
|
|
|
|
int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);
|
2006-06-18 11:37:28 +08:00
|
|
|
|
|
|
|
static inline u16 ib_addr_get_pkey(struct rdma_dev_addr *dev_addr)
|
|
|
|
{
|
|
|
|
return ((u16)dev_addr->broadcast[8] << 8) | (u16)dev_addr->broadcast[9];
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void ib_addr_set_pkey(struct rdma_dev_addr *dev_addr, u16 pkey)
|
|
|
|
{
|
|
|
|
dev_addr->broadcast[8] = pkey >> 8;
|
|
|
|
dev_addr->broadcast[9] = (unsigned char) pkey;
|
|
|
|
}
|
|
|
|
|
2007-02-16 09:00:17 +08:00
|
|
|
static inline void ib_addr_get_mgid(struct rdma_dev_addr *dev_addr,
|
|
|
|
union ib_gid *gid)
|
|
|
|
{
|
|
|
|
memcpy(gid, dev_addr->broadcast + 4, sizeof *gid);
|
|
|
|
}
|
|
|
|
|
RDMA/cm: fix loopback address support
The RDMA CM is intended to support the use of a loopback address
when establishing a connection; however, the behavior of the CM
when loopback addresses are used is confusing and does not always
work, depending on whether loopback was specified by the server,
the client, or both.
The defined behavior of rdma_bind_addr is to associate an RDMA
device with an rdma_cm_id, as long as the user specified a non-
zero address. (ie they weren't just trying to reserve a port)
Currently, if the loopback address is passed to rdam_bind_addr,
no device is associated with the rdma_cm_id. Fix this.
If a loopback address is specified by the client as the destination
address for a connection, it will fail to establish a connection.
This is true even if the server is listing across all addresses or
on the loopback address itself. The issue is that the server tries
to translate the IP address carried in the REQ message to a local
net_device address, which fails. The translation is not needed in
this case, since the REQ carries the actual HW address that should
be used.
Finally, cleanup loopback support to be more transport neutral.
Replace separate calls to get/set the sgid and dgid from the
device address to a single call that behaves correctly depending
on the format of the device address. And support both IPv4 and
IPv6 address formats.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
[ Fixed RDS build by s/ib_addr_get/rdma_addr_get/ - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2009-11-20 05:26:06 +08:00
|
|
|
static inline int rdma_addr_gid_offset(struct rdma_dev_addr *dev_addr)
|
2006-06-18 11:37:28 +08:00
|
|
|
{
|
RDMA/cm: fix loopback address support
The RDMA CM is intended to support the use of a loopback address
when establishing a connection; however, the behavior of the CM
when loopback addresses are used is confusing and does not always
work, depending on whether loopback was specified by the server,
the client, or both.
The defined behavior of rdma_bind_addr is to associate an RDMA
device with an rdma_cm_id, as long as the user specified a non-
zero address. (ie they weren't just trying to reserve a port)
Currently, if the loopback address is passed to rdam_bind_addr,
no device is associated with the rdma_cm_id. Fix this.
If a loopback address is specified by the client as the destination
address for a connection, it will fail to establish a connection.
This is true even if the server is listing across all addresses or
on the loopback address itself. The issue is that the server tries
to translate the IP address carried in the REQ message to a local
net_device address, which fails. The translation is not needed in
this case, since the REQ carries the actual HW address that should
be used.
Finally, cleanup loopback support to be more transport neutral.
Replace separate calls to get/set the sgid and dgid from the
device address to a single call that behaves correctly depending
on the format of the device address. And support both IPv4 and
IPv6 address formats.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
[ Fixed RDS build by s/ib_addr_get/rdma_addr_get/ - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2009-11-20 05:26:06 +08:00
|
|
|
return dev_addr->dev_type == ARPHRD_INFINIBAND ? 4 : 0;
|
2006-06-18 11:37:28 +08:00
|
|
|
}
|
|
|
|
|
2013-12-13 00:03:12 +08:00
|
|
|
static inline u16 rdma_vlan_dev_vlan_id(const struct net_device *dev)
|
2010-10-14 03:26:51 +08:00
|
|
|
{
|
2017-02-05 01:00:49 +08:00
|
|
|
return is_vlan_dev(dev) ? vlan_dev_vlan_id(dev) : 0xffff;
|
2010-10-14 03:26:51 +08:00
|
|
|
}
|
|
|
|
|
IB/core: Ethernet L2 attributes in verbs/cm structures
This patch add the support for Ethernet L2 attributes in the
verbs/cm/cma structures.
When dealing with L2 Ethernet, we should use smac, dmac, vlan ID and priority
in a similar manner that the IB L2 (and the L4 PKEY) attributes are used.
Thus, those attributes were added to the following structures:
* ib_ah_attr - added dmac
* ib_qp_attr - added smac and vlan_id, (sl remains vlan priority)
* ib_wc - added smac, vlan_id
* ib_sa_path_rec - added smac, dmac, vlan_id
* cm_av - added smac and vlan_id
For the path record structure, extra care was taken to avoid the new
fields when packing it into wire format, so we don't break the IB CM
and SA wire protocol.
On the active side, the CM fills. its internal structures from the
path provided by the ULP. We add there taking the ETH L2 attributes
and placing them into the CM Address Handle (struct cm_av).
On the passive side, the CM fills its internal structures from the WC
associated with the REQ message. We add there taking the ETH L2
attributes from the WC.
When the HW driver provides the required ETH L2 attributes in the WC,
they set the IB_WC_WITH_SMAC and IB_WC_WITH_VLAN flags. The IB core
code checks for the presence of these flags, and in their absence does
address resolution from the ib_init_ah_from_wc() helper function.
ib_modify_qp_is_ok is also updated to consider the link layer. Some
parameters are mandatory for Ethernet link layer, while they are
irrelevant for IB. Vendor drivers are modified to support the new
function signature.
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-12-13 00:03:11 +08:00
|
|
|
static inline int rdma_ip2gid(struct sockaddr *addr, union ib_gid *gid)
|
|
|
|
{
|
|
|
|
switch (addr->sa_family) {
|
|
|
|
case AF_INET:
|
|
|
|
ipv6_addr_set_v4mapped(((struct sockaddr_in *)
|
|
|
|
addr)->sin_addr.s_addr,
|
|
|
|
(struct in6_addr *)gid);
|
|
|
|
break;
|
|
|
|
case AF_INET6:
|
2017-07-31 14:50:05 +08:00
|
|
|
*(struct in6_addr *)&gid->raw =
|
|
|
|
((struct sockaddr_in6 *)addr)->sin6_addr;
|
IB/core: Ethernet L2 attributes in verbs/cm structures
This patch add the support for Ethernet L2 attributes in the
verbs/cm/cma structures.
When dealing with L2 Ethernet, we should use smac, dmac, vlan ID and priority
in a similar manner that the IB L2 (and the L4 PKEY) attributes are used.
Thus, those attributes were added to the following structures:
* ib_ah_attr - added dmac
* ib_qp_attr - added smac and vlan_id, (sl remains vlan priority)
* ib_wc - added smac, vlan_id
* ib_sa_path_rec - added smac, dmac, vlan_id
* cm_av - added smac and vlan_id
For the path record structure, extra care was taken to avoid the new
fields when packing it into wire format, so we don't break the IB CM
and SA wire protocol.
On the active side, the CM fills. its internal structures from the
path provided by the ULP. We add there taking the ETH L2 attributes
and placing them into the CM Address Handle (struct cm_av).
On the passive side, the CM fills its internal structures from the WC
associated with the REQ message. We add there taking the ETH L2
attributes from the WC.
When the HW driver provides the required ETH L2 attributes in the WC,
they set the IB_WC_WITH_SMAC and IB_WC_WITH_VLAN flags. The IB core
code checks for the presence of these flags, and in their absence does
address resolution from the ib_init_ah_from_wc() helper function.
ib_modify_qp_is_ok is also updated to consider the link layer. Some
parameters are mandatory for Ethernet link layer, while they are
irrelevant for IB. Vendor drivers are modified to support the new
function signature.
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-12-13 00:03:11 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Important - sockaddr should be a union of sockaddr_in and sockaddr_in6 */
|
2015-06-01 05:15:31 +08:00
|
|
|
static inline void rdma_gid2ip(struct sockaddr *out, const union ib_gid *gid)
|
IB/core: Ethernet L2 attributes in verbs/cm structures
This patch add the support for Ethernet L2 attributes in the
verbs/cm/cma structures.
When dealing with L2 Ethernet, we should use smac, dmac, vlan ID and priority
in a similar manner that the IB L2 (and the L4 PKEY) attributes are used.
Thus, those attributes were added to the following structures:
* ib_ah_attr - added dmac
* ib_qp_attr - added smac and vlan_id, (sl remains vlan priority)
* ib_wc - added smac, vlan_id
* ib_sa_path_rec - added smac, dmac, vlan_id
* cm_av - added smac and vlan_id
For the path record structure, extra care was taken to avoid the new
fields when packing it into wire format, so we don't break the IB CM
and SA wire protocol.
On the active side, the CM fills. its internal structures from the
path provided by the ULP. We add there taking the ETH L2 attributes
and placing them into the CM Address Handle (struct cm_av).
On the passive side, the CM fills its internal structures from the WC
associated with the REQ message. We add there taking the ETH L2
attributes from the WC.
When the HW driver provides the required ETH L2 attributes in the WC,
they set the IB_WC_WITH_SMAC and IB_WC_WITH_VLAN flags. The IB core
code checks for the presence of these flags, and in their absence does
address resolution from the ib_init_ah_from_wc() helper function.
ib_modify_qp_is_ok is also updated to consider the link layer. Some
parameters are mandatory for Ethernet link layer, while they are
irrelevant for IB. Vendor drivers are modified to support the new
function signature.
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-12-13 00:03:11 +08:00
|
|
|
{
|
|
|
|
if (ipv6_addr_v4mapped((struct in6_addr *)gid)) {
|
|
|
|
struct sockaddr_in *out_in = (struct sockaddr_in *)out;
|
|
|
|
memset(out_in, 0, sizeof(*out_in));
|
|
|
|
out_in->sin_family = AF_INET;
|
|
|
|
memcpy(&out_in->sin_addr.s_addr, gid->raw + 12, 4);
|
|
|
|
} else {
|
|
|
|
struct sockaddr_in6 *out_in = (struct sockaddr_in6 *)out;
|
|
|
|
memset(out_in, 0, sizeof(*out_in));
|
|
|
|
out_in->sin6_family = AF_INET6;
|
|
|
|
memcpy(&out_in->sin6_addr.s6_addr, gid->raw, 16);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-01-18 16:11:19 +08:00
|
|
|
/*
|
|
|
|
* rdma_get/set_sgid/dgid() APIs are applicable to IB, and iWarp.
|
|
|
|
* They are not applicable to RoCE.
|
|
|
|
* RoCE GIDs are derived from the IP addresses.
|
|
|
|
*/
|
RDMA/cm: fix loopback address support
The RDMA CM is intended to support the use of a loopback address
when establishing a connection; however, the behavior of the CM
when loopback addresses are used is confusing and does not always
work, depending on whether loopback was specified by the server,
the client, or both.
The defined behavior of rdma_bind_addr is to associate an RDMA
device with an rdma_cm_id, as long as the user specified a non-
zero address. (ie they weren't just trying to reserve a port)
Currently, if the loopback address is passed to rdam_bind_addr,
no device is associated with the rdma_cm_id. Fix this.
If a loopback address is specified by the client as the destination
address for a connection, it will fail to establish a connection.
This is true even if the server is listing across all addresses or
on the loopback address itself. The issue is that the server tries
to translate the IP address carried in the REQ message to a local
net_device address, which fails. The translation is not needed in
this case, since the REQ carries the actual HW address that should
be used.
Finally, cleanup loopback support to be more transport neutral.
Replace separate calls to get/set the sgid and dgid from the
device address to a single call that behaves correctly depending
on the format of the device address. And support both IPv4 and
IPv6 address formats.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
[ Fixed RDS build by s/ib_addr_get/rdma_addr_get/ - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2009-11-20 05:26:06 +08:00
|
|
|
static inline void rdma_addr_get_sgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
|
2006-06-18 11:37:28 +08:00
|
|
|
{
|
2018-01-18 16:11:19 +08:00
|
|
|
memcpy(gid, dev_addr->src_dev_addr + rdma_addr_gid_offset(dev_addr),
|
|
|
|
sizeof(*gid));
|
2006-06-18 11:37:28 +08:00
|
|
|
}
|
|
|
|
|
RDMA/cm: fix loopback address support
The RDMA CM is intended to support the use of a loopback address
when establishing a connection; however, the behavior of the CM
when loopback addresses are used is confusing and does not always
work, depending on whether loopback was specified by the server,
the client, or both.
The defined behavior of rdma_bind_addr is to associate an RDMA
device with an rdma_cm_id, as long as the user specified a non-
zero address. (ie they weren't just trying to reserve a port)
Currently, if the loopback address is passed to rdam_bind_addr,
no device is associated with the rdma_cm_id. Fix this.
If a loopback address is specified by the client as the destination
address for a connection, it will fail to establish a connection.
This is true even if the server is listing across all addresses or
on the loopback address itself. The issue is that the server tries
to translate the IP address carried in the REQ message to a local
net_device address, which fails. The translation is not needed in
this case, since the REQ carries the actual HW address that should
be used.
Finally, cleanup loopback support to be more transport neutral.
Replace separate calls to get/set the sgid and dgid from the
device address to a single call that behaves correctly depending
on the format of the device address. And support both IPv4 and
IPv6 address formats.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
[ Fixed RDS build by s/ib_addr_get/rdma_addr_get/ - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2009-11-20 05:26:06 +08:00
|
|
|
static inline void rdma_addr_set_sgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
|
2006-06-18 11:37:28 +08:00
|
|
|
{
|
RDMA/cm: fix loopback address support
The RDMA CM is intended to support the use of a loopback address
when establishing a connection; however, the behavior of the CM
when loopback addresses are used is confusing and does not always
work, depending on whether loopback was specified by the server,
the client, or both.
The defined behavior of rdma_bind_addr is to associate an RDMA
device with an rdma_cm_id, as long as the user specified a non-
zero address. (ie they weren't just trying to reserve a port)
Currently, if the loopback address is passed to rdam_bind_addr,
no device is associated with the rdma_cm_id. Fix this.
If a loopback address is specified by the client as the destination
address for a connection, it will fail to establish a connection.
This is true even if the server is listing across all addresses or
on the loopback address itself. The issue is that the server tries
to translate the IP address carried in the REQ message to a local
net_device address, which fails. The translation is not needed in
this case, since the REQ carries the actual HW address that should
be used.
Finally, cleanup loopback support to be more transport neutral.
Replace separate calls to get/set the sgid and dgid from the
device address to a single call that behaves correctly depending
on the format of the device address. And support both IPv4 and
IPv6 address formats.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
[ Fixed RDS build by s/ib_addr_get/rdma_addr_get/ - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2009-11-20 05:26:06 +08:00
|
|
|
memcpy(dev_addr->src_dev_addr + rdma_addr_gid_offset(dev_addr), gid, sizeof *gid);
|
2006-06-18 11:37:28 +08:00
|
|
|
}
|
|
|
|
|
RDMA/cm: fix loopback address support
The RDMA CM is intended to support the use of a loopback address
when establishing a connection; however, the behavior of the CM
when loopback addresses are used is confusing and does not always
work, depending on whether loopback was specified by the server,
the client, or both.
The defined behavior of rdma_bind_addr is to associate an RDMA
device with an rdma_cm_id, as long as the user specified a non-
zero address. (ie they weren't just trying to reserve a port)
Currently, if the loopback address is passed to rdam_bind_addr,
no device is associated with the rdma_cm_id. Fix this.
If a loopback address is specified by the client as the destination
address for a connection, it will fail to establish a connection.
This is true even if the server is listing across all addresses or
on the loopback address itself. The issue is that the server tries
to translate the IP address carried in the REQ message to a local
net_device address, which fails. The translation is not needed in
this case, since the REQ carries the actual HW address that should
be used.
Finally, cleanup loopback support to be more transport neutral.
Replace separate calls to get/set the sgid and dgid from the
device address to a single call that behaves correctly depending
on the format of the device address. And support both IPv4 and
IPv6 address formats.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
[ Fixed RDS build by s/ib_addr_get/rdma_addr_get/ - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2009-11-20 05:26:06 +08:00
|
|
|
static inline void rdma_addr_get_dgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
|
2006-06-18 11:37:28 +08:00
|
|
|
{
|
RDMA/cm: fix loopback address support
The RDMA CM is intended to support the use of a loopback address
when establishing a connection; however, the behavior of the CM
when loopback addresses are used is confusing and does not always
work, depending on whether loopback was specified by the server,
the client, or both.
The defined behavior of rdma_bind_addr is to associate an RDMA
device with an rdma_cm_id, as long as the user specified a non-
zero address. (ie they weren't just trying to reserve a port)
Currently, if the loopback address is passed to rdam_bind_addr,
no device is associated with the rdma_cm_id. Fix this.
If a loopback address is specified by the client as the destination
address for a connection, it will fail to establish a connection.
This is true even if the server is listing across all addresses or
on the loopback address itself. The issue is that the server tries
to translate the IP address carried in the REQ message to a local
net_device address, which fails. The translation is not needed in
this case, since the REQ carries the actual HW address that should
be used.
Finally, cleanup loopback support to be more transport neutral.
Replace separate calls to get/set the sgid and dgid from the
device address to a single call that behaves correctly depending
on the format of the device address. And support both IPv4 and
IPv6 address formats.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
[ Fixed RDS build by s/ib_addr_get/rdma_addr_get/ - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2009-11-20 05:26:06 +08:00
|
|
|
memcpy(gid, dev_addr->dst_dev_addr + rdma_addr_gid_offset(dev_addr), sizeof *gid);
|
2006-06-18 11:37:28 +08:00
|
|
|
}
|
|
|
|
|
RDMA/cm: fix loopback address support
The RDMA CM is intended to support the use of a loopback address
when establishing a connection; however, the behavior of the CM
when loopback addresses are used is confusing and does not always
work, depending on whether loopback was specified by the server,
the client, or both.
The defined behavior of rdma_bind_addr is to associate an RDMA
device with an rdma_cm_id, as long as the user specified a non-
zero address. (ie they weren't just trying to reserve a port)
Currently, if the loopback address is passed to rdam_bind_addr,
no device is associated with the rdma_cm_id. Fix this.
If a loopback address is specified by the client as the destination
address for a connection, it will fail to establish a connection.
This is true even if the server is listing across all addresses or
on the loopback address itself. The issue is that the server tries
to translate the IP address carried in the REQ message to a local
net_device address, which fails. The translation is not needed in
this case, since the REQ carries the actual HW address that should
be used.
Finally, cleanup loopback support to be more transport neutral.
Replace separate calls to get/set the sgid and dgid from the
device address to a single call that behaves correctly depending
on the format of the device address. And support both IPv4 and
IPv6 address formats.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
[ Fixed RDS build by s/ib_addr_get/rdma_addr_get/ - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2009-11-20 05:26:06 +08:00
|
|
|
static inline void rdma_addr_set_dgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
|
2006-08-04 05:02:42 +08:00
|
|
|
{
|
RDMA/cm: fix loopback address support
The RDMA CM is intended to support the use of a loopback address
when establishing a connection; however, the behavior of the CM
when loopback addresses are used is confusing and does not always
work, depending on whether loopback was specified by the server,
the client, or both.
The defined behavior of rdma_bind_addr is to associate an RDMA
device with an rdma_cm_id, as long as the user specified a non-
zero address. (ie they weren't just trying to reserve a port)
Currently, if the loopback address is passed to rdam_bind_addr,
no device is associated with the rdma_cm_id. Fix this.
If a loopback address is specified by the client as the destination
address for a connection, it will fail to establish a connection.
This is true even if the server is listing across all addresses or
on the loopback address itself. The issue is that the server tries
to translate the IP address carried in the REQ message to a local
net_device address, which fails. The translation is not needed in
this case, since the REQ carries the actual HW address that should
be used.
Finally, cleanup loopback support to be more transport neutral.
Replace separate calls to get/set the sgid and dgid from the
device address to a single call that behaves correctly depending
on the format of the device address. And support both IPv4 and
IPv6 address formats.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
[ Fixed RDS build by s/ib_addr_get/rdma_addr_get/ - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2009-11-20 05:26:06 +08:00
|
|
|
memcpy(dev_addr->dst_dev_addr + rdma_addr_gid_offset(dev_addr), gid, sizeof *gid);
|
2006-08-04 05:02:42 +08:00
|
|
|
}
|
|
|
|
|
2010-10-14 03:26:51 +08:00
|
|
|
static inline enum ib_mtu iboe_get_mtu(int mtu)
|
|
|
|
{
|
|
|
|
/*
|
2017-10-16 13:45:16 +08:00
|
|
|
* Reduce IB headers from effective IBoE MTU.
|
2010-10-14 03:26:51 +08:00
|
|
|
*/
|
2017-10-16 13:45:16 +08:00
|
|
|
mtu = mtu - (IB_GRH_BYTES + IB_UDP_BYTES + IB_BTH_BYTES +
|
|
|
|
IB_EXT_XRC_BYTES + IB_EXT_ATOMICETH_BYTES +
|
|
|
|
IB_ICRC_BYTES);
|
2010-10-14 03:26:51 +08:00
|
|
|
|
|
|
|
if (mtu >= ib_mtu_enum_to_int(IB_MTU_4096))
|
|
|
|
return IB_MTU_4096;
|
|
|
|
else if (mtu >= ib_mtu_enum_to_int(IB_MTU_2048))
|
|
|
|
return IB_MTU_2048;
|
|
|
|
else if (mtu >= ib_mtu_enum_to_int(IB_MTU_1024))
|
|
|
|
return IB_MTU_1024;
|
|
|
|
else if (mtu >= ib_mtu_enum_to_int(IB_MTU_512))
|
|
|
|
return IB_MTU_512;
|
|
|
|
else if (mtu >= ib_mtu_enum_to_int(IB_MTU_256))
|
|
|
|
return IB_MTU_256;
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int rdma_link_local_addr(struct in6_addr *addr)
|
|
|
|
{
|
|
|
|
if (addr->s6_addr32[0] == htonl(0xfe800000) &&
|
|
|
|
addr->s6_addr32[1] == 0)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void rdma_get_ll_mac(struct in6_addr *addr, u8 *mac)
|
|
|
|
{
|
|
|
|
memcpy(mac, &addr->s6_addr[8], 3);
|
|
|
|
memcpy(mac + 3, &addr->s6_addr[13], 3);
|
|
|
|
mac[0] ^= 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int rdma_is_multicast_addr(struct in6_addr *addr)
|
|
|
|
{
|
2017-10-12 01:48:43 +08:00
|
|
|
__be32 ipv4_addr;
|
2017-06-12 16:14:03 +08:00
|
|
|
|
|
|
|
if (addr->s6_addr[0] == 0xff)
|
|
|
|
return 1;
|
|
|
|
|
2017-10-12 01:48:43 +08:00
|
|
|
ipv4_addr = addr->s6_addr32[3];
|
2017-06-12 16:14:03 +08:00
|
|
|
return (ipv6_addr_v4mapped(addr) && ipv4_is_multicast(ipv4_addr));
|
2010-10-14 03:26:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void rdma_get_mcast_mac(struct in6_addr *addr, u8 *mac)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
mac[0] = 0x33;
|
|
|
|
mac[1] = 0x33;
|
|
|
|
for (i = 2; i < 6; ++i)
|
|
|
|
mac[i] = addr->s6_addr[i + 10];
|
|
|
|
}
|
|
|
|
|
2010-08-26 22:18:59 +08:00
|
|
|
static inline u16 rdma_get_vlan_id(union ib_gid *dgid)
|
|
|
|
{
|
|
|
|
u16 vid;
|
|
|
|
|
|
|
|
vid = dgid->raw[11] << 8 | dgid->raw[12];
|
|
|
|
return vid < 0x1000 ? vid : 0xffff;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct net_device *rdma_vlan_dev_real_dev(const struct net_device *dev)
|
|
|
|
{
|
2017-02-05 01:00:49 +08:00
|
|
|
return is_vlan_dev(dev) ? vlan_dev_real_dev(dev) : NULL;
|
2010-08-26 22:18:59 +08:00
|
|
|
}
|
|
|
|
|
2006-06-18 11:37:28 +08:00
|
|
|
#endif /* IB_ADDR_H */
|