2006-06-18 03:37:28 +00:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2005 Voltaire Inc. All rights reserved.
|
|
|
|
* Copyright (c) 2005 Intel Corporation. All rights reserved.
|
|
|
|
*
|
2008-07-15 06:48:43 +00:00
|
|
|
* This software is available to you under a choice of one of two
|
|
|
|
* licenses. You may choose to be licensed under the terms of the GNU
|
|
|
|
* General Public License (GPL) Version 2, available from the file
|
|
|
|
* COPYING in the main directory of this source tree, or the
|
|
|
|
* OpenIB.org BSD license below:
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or
|
|
|
|
* without modification, are permitted provided that the following
|
|
|
|
* conditions are met:
|
|
|
|
*
|
|
|
|
* - Redistributions of source code must retain the above
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
* disclaimer.
|
|
|
|
*
|
|
|
|
* - Redistributions in binary form must reproduce the above
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
* disclaimer in the documentation and/or other materials
|
|
|
|
* provided with the distribution.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
* SOFTWARE.
|
2006-06-18 03:37:28 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#if !defined(IB_ADDR_H)
|
|
|
|
#define IB_ADDR_H
|
|
|
|
|
|
|
|
#include <linux/in.h>
|
|
|
|
#include <linux/in6.h>
|
2009-11-19 20:57:18 +00:00
|
|
|
#include <linux/if_arp.h>
|
2006-06-18 03:37:28 +00:00
|
|
|
#include <linux/netdevice.h>
|
|
|
|
#include <linux/socket.h>
|
2010-08-26 14:18:59 +00:00
|
|
|
#include <linux/if_vlan.h>
|
2006-06-18 03:37:28 +00:00
|
|
|
#include <rdma/ib_verbs.h>
|
2010-10-13 19:26:51 +00:00
|
|
|
#include <rdma/ib_pack.h>
|
2006-06-18 03:37:28 +00:00
|
|
|
|
2006-10-31 19:12:59 +00:00
|
|
|
struct rdma_addr_client {
|
|
|
|
atomic_t refcount;
|
|
|
|
struct completion comp;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rdma_addr_register_client - Register an address client.
|
|
|
|
*/
|
|
|
|
void rdma_addr_register_client(struct rdma_addr_client *client);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rdma_addr_unregister_client - Deregister an address client.
|
|
|
|
* @client: Client object to deregister.
|
|
|
|
*/
|
|
|
|
void rdma_addr_unregister_client(struct rdma_addr_client *client);
|
|
|
|
|
2006-06-18 03:37:28 +00: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-19 20:57:18 +00:00
|
|
|
unsigned short dev_type;
|
2009-11-19 20:55:22 +00:00
|
|
|
int bound_dev_if;
|
2010-10-13 19:26:51 +00:00
|
|
|
enum rdma_transport_type transport;
|
2006-06-18 03:37:28 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rdma_translate_ip - Translate a local IP address to an RDMA hardware
|
|
|
|
* address.
|
|
|
|
*/
|
|
|
|
int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rdma_resolve_ip - Resolve source and destination IP addresses to
|
|
|
|
* RDMA hardware addresses.
|
2006-10-31 19:12:59 +00:00
|
|
|
* @client: Address client associated with request.
|
2006-06-18 03:37:28 +00:00
|
|
|
* @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
|
|
|
|
* been invoked.
|
|
|
|
* @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.
|
|
|
|
* @context: User-specified context associated with the call.
|
|
|
|
*/
|
2006-10-31 19:12:59 +00:00
|
|
|
int rdma_resolve_ip(struct rdma_addr_client *client,
|
|
|
|
struct sockaddr *src_addr, struct sockaddr *dst_addr,
|
2006-06-18 03:37:28 +00:00
|
|
|
struct rdma_dev_addr *addr, int timeout_ms,
|
|
|
|
void (*callback)(int status, struct sockaddr *src_addr,
|
|
|
|
struct rdma_dev_addr *addr, void *context),
|
|
|
|
void *context);
|
|
|
|
|
|
|
|
void rdma_addr_cancel(struct rdma_dev_addr *addr);
|
|
|
|
|
2006-08-03 21:02:42 +00:00
|
|
|
int rdma_copy_addr(struct rdma_dev_addr *dev_addr, struct net_device *dev,
|
|
|
|
const unsigned char *dst_dev_addr);
|
|
|
|
|
2006-06-18 03:37:28 +00:00
|
|
|
static inline int ip_addr_size(struct sockaddr *addr)
|
|
|
|
{
|
|
|
|
return addr->sa_family == AF_INET6 ?
|
|
|
|
sizeof(struct sockaddr_in6) : sizeof(struct sockaddr_in);
|
|
|
|
}
|
|
|
|
|
|
|
|
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 01:00:17 +00: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-19 21:26:06 +00:00
|
|
|
static inline int rdma_addr_gid_offset(struct rdma_dev_addr *dev_addr)
|
2006-06-18 03:37:28 +00: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-19 21:26:06 +00:00
|
|
|
return dev_addr->dev_type == ARPHRD_INFINIBAND ? 4 : 0;
|
2006-06-18 03:37:28 +00:00
|
|
|
}
|
|
|
|
|
2010-08-26 14:18:59 +00:00
|
|
|
static inline void iboe_mac_vlan_to_ll(union ib_gid *gid, u8 *mac, u16 vid)
|
2010-10-13 19:26:51 +00:00
|
|
|
{
|
|
|
|
memset(gid->raw, 0, 16);
|
|
|
|
*((__be32 *) gid->raw) = cpu_to_be32(0xfe800000);
|
2010-08-26 14:18:59 +00:00
|
|
|
if (vid < 0x1000) {
|
|
|
|
gid->raw[12] = vid & 0xff;
|
|
|
|
gid->raw[11] = vid >> 8;
|
|
|
|
} else {
|
|
|
|
gid->raw[12] = 0xfe;
|
|
|
|
gid->raw[11] = 0xff;
|
|
|
|
}
|
2010-10-13 19:26:51 +00:00
|
|
|
memcpy(gid->raw + 13, mac + 3, 3);
|
|
|
|
memcpy(gid->raw + 8, mac, 3);
|
|
|
|
gid->raw[8] ^= 2;
|
|
|
|
}
|
|
|
|
|
2010-08-26 14:18:59 +00:00
|
|
|
static inline u16 rdma_vlan_dev_vlan_id(const struct net_device *dev)
|
|
|
|
{
|
|
|
|
return dev->priv_flags & IFF_802_1Q_VLAN ?
|
|
|
|
vlan_dev_vlan_id(dev) : 0xffff;
|
|
|
|
}
|
|
|
|
|
2010-10-13 19:26:51 +00:00
|
|
|
static inline void iboe_addr_get_sgid(struct rdma_dev_addr *dev_addr,
|
|
|
|
union ib_gid *gid)
|
|
|
|
{
|
2010-08-26 14:18:59 +00:00
|
|
|
struct net_device *dev;
|
|
|
|
u16 vid = 0xffff;
|
|
|
|
|
|
|
|
dev = dev_get_by_index(&init_net, dev_addr->bound_dev_if);
|
|
|
|
if (dev) {
|
|
|
|
vid = rdma_vlan_dev_vlan_id(dev);
|
|
|
|
dev_put(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
iboe_mac_vlan_to_ll(gid, dev_addr->src_dev_addr, vid);
|
2010-10-13 19:26:51 +00: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-19 21:26:06 +00:00
|
|
|
static inline void rdma_addr_get_sgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
|
2006-06-18 03:37:28 +00:00
|
|
|
{
|
2010-10-13 19:26:51 +00:00
|
|
|
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);
|
2006-06-18 03:37:28 +00: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-19 21:26:06 +00:00
|
|
|
static inline void rdma_addr_set_sgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
|
2006-06-18 03:37:28 +00: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-19 21:26:06 +00:00
|
|
|
memcpy(dev_addr->src_dev_addr + rdma_addr_gid_offset(dev_addr), gid, sizeof *gid);
|
2006-06-18 03:37:28 +00: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-19 21:26:06 +00:00
|
|
|
static inline void rdma_addr_get_dgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
|
2006-06-18 03:37:28 +00: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-19 21:26:06 +00:00
|
|
|
memcpy(gid, dev_addr->dst_dev_addr + rdma_addr_gid_offset(dev_addr), sizeof *gid);
|
2006-06-18 03:37:28 +00: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-19 21:26:06 +00:00
|
|
|
static inline void rdma_addr_set_dgid(struct rdma_dev_addr *dev_addr, union ib_gid *gid)
|
2006-08-03 21:02:42 +00: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-19 21:26:06 +00:00
|
|
|
memcpy(dev_addr->dst_dev_addr + rdma_addr_gid_offset(dev_addr), gid, sizeof *gid);
|
2006-08-03 21:02:42 +00:00
|
|
|
}
|
|
|
|
|
2010-10-13 19:26:51 +00:00
|
|
|
static inline enum ib_mtu iboe_get_mtu(int mtu)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* reduce IB headers from effective IBoE MTU. 28 stands for
|
|
|
|
* atomic header which is the biggest possible header after BTH
|
|
|
|
*/
|
|
|
|
mtu = mtu - IB_GRH_BYTES - IB_BTH_BYTES - 28;
|
|
|
|
|
|
|
|
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 iboe_get_rate(struct net_device *dev)
|
|
|
|
{
|
|
|
|
struct ethtool_cmd cmd;
|
2011-04-27 18:32:38 +00:00
|
|
|
u32 speed;
|
2011-09-03 03:34:30 +00:00
|
|
|
int err;
|
2010-10-13 19:26:51 +00:00
|
|
|
|
2011-09-03 03:34:30 +00:00
|
|
|
rtnl_lock();
|
|
|
|
err = __ethtool_get_settings(dev, &cmd);
|
|
|
|
rtnl_unlock();
|
|
|
|
if (err)
|
2010-10-13 19:26:51 +00:00
|
|
|
return IB_RATE_PORT_CURRENT;
|
|
|
|
|
2011-04-27 18:32:38 +00:00
|
|
|
speed = ethtool_cmd_speed(&cmd);
|
|
|
|
if (speed >= 40000)
|
2010-10-13 19:26:51 +00:00
|
|
|
return IB_RATE_40_GBPS;
|
2011-04-27 18:32:38 +00:00
|
|
|
else if (speed >= 30000)
|
2010-10-13 19:26:51 +00:00
|
|
|
return IB_RATE_30_GBPS;
|
2011-04-27 18:32:38 +00:00
|
|
|
else if (speed >= 20000)
|
2010-10-13 19:26:51 +00:00
|
|
|
return IB_RATE_20_GBPS;
|
2011-04-27 18:32:38 +00:00
|
|
|
else if (speed >= 10000)
|
2010-10-13 19:26:51 +00:00
|
|
|
return IB_RATE_10_GBPS;
|
|
|
|
else
|
|
|
|
return IB_RATE_PORT_CURRENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
return addr->s6_addr[0] == 0xff;
|
|
|
|
}
|
|
|
|
|
|
|
|
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 14:18:59 +00: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)
|
|
|
|
{
|
|
|
|
return dev->priv_flags & IFF_802_1Q_VLAN ?
|
2011-12-06 21:13:10 +00:00
|
|
|
vlan_dev_real_dev(dev) : NULL;
|
2010-08-26 14:18:59 +00:00
|
|
|
}
|
|
|
|
|
2006-06-18 03:37:28 +00:00
|
|
|
#endif /* IB_ADDR_H */
|