Re: [PATCH for-next 3/9] net/mlx4_core: Set initial admin GUIDs for VFs
On 3/30/2015 8:16 PM, Jason Gunthorpe wrote: But, it doesn't really make sense to use eth_random_addr (which doesn't have a special OUI) and not randomize every bit. get_random_bytes(&guid, sizeof(guid)); guid &= ~(1ULL << 56); guid |= 1ULL << 57; OK, we can do that, sure. I also don't think the kernel should be generating random GUIDs. Either the SA should be consulted to do this, or the management stack should generate a cloud wide unique number. There **is** an option to consult with the SM controlled by the sm_guid_assign module param of mlx4_ib. When this mode is in action, the randomized guid would be overridden by the one assigned by the SA. In real life environments, people will use the "host assigned" option (sm_guid_assign = false) where the virtualization systems generate a unique guid to be used by the VF/VM and provision it through mlx4_ib to be provided to VF when the bindin. The only place where the random value will be used, is for OOTB experience for staging purposes and such, when one wants to have working system with zero-touch. The practice of generating locally random address for non-provisioned VF is also used by the pretty much the whole set of Ethernet VF drivers (ixgbe_vf, i40e_vf, mlx4 VF code, etc). This is low cost solution for point cases which need that. Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH for-next 3/9] net/mlx4_core: Set initial admin GUIDs for VFs
On Sun, Mar 29, 2015 at 04:51:27PM +0300, Or Gerlitz wrote:
> +void mlx4_set_random_admin_guid(struct mlx4_dev *dev, int entry, int port)
> +{
> + struct mlx4_priv *priv = mlx4_priv(dev);
> + u8 random_mac[6];
> + char *raw_gid;
> +
> + /* hw GUID */
> + if (entry == 0)
> + return;
> +
> + eth_random_addr(random_mac);
> + raw_gid = (char *)&priv->mfunc.master.vf_admin[entry].vport[port].guid;
raw_gid is actually a guid
> + raw_gid[0] = random_mac[0] ^ 2;
eth_random_addr already guarentees the ULA bit is set to one (local),
so this is wrong. IBA uses the EUI-64 system, not the IPv6
modification.
> + raw_gid[1] = random_mac[1];
> + raw_gid[2] = random_mac[2];
> + raw_gid[3] = 0xff;
> + raw_gid[4] = 0xfe;
This should be 0xff for mapping a MAC to a EUI-64
But, it doesn't really make sense to use eth_random_addr (which
doesn't have a special OUI) and not randomize every bit.
get_random_bytes(&guid, sizeof(guid));
guid &= ~(1ULL << 56);
guid |= 1ULL << 57;
I also don't think the kernel should be generating random GUIDs. Either
the SA should be consulted to do this, or the management stack should
generate a cloud wide unique number.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for-next 3/9] net/mlx4_core: Set initial admin GUIDs for VFs
From: Yishai Hadas
To have out of the box experience, the PF generates random GUIDs who
serve as the initial admin values.
Signed-off-by: Yishai Hadas
Signed-off-by: Jack Morgenstein
Signed-off-by: Or Gerlitz
---
drivers/net/ethernet/mellanox/mlx4/cmd.c |1 +
drivers/net/ethernet/mellanox/mlx4/main.c | 23 +++
include/linux/mlx4/device.h |1 +
3 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c
b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 20b3c7b..778de74 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -2255,6 +2255,7 @@ int mlx4_multi_func_init(struct mlx4_dev *dev)
priv->mfunc.master.vf_oper[i].vport[port].state.default_vlan = MLX4_VGT;
priv->mfunc.master.vf_oper[i].vport[port].vlan_idx = NO_INDX;
priv->mfunc.master.vf_oper[i].vport[port].mac_idx = NO_INDX;
+ mlx4_set_random_admin_guid(dev, i, port);
}
spin_lock_init(&s_state->lock);
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c
b/drivers/net/ethernet/mellanox/mlx4/main.c
index 6d1f10e..67e57e5 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2245,6 +2246,28 @@ __be64 mlx4_get_admin_guid(struct mlx4_dev *dev, int
entry, int port)
}
EXPORT_SYMBOL_GPL(mlx4_get_admin_guid);
+void mlx4_set_random_admin_guid(struct mlx4_dev *dev, int entry, int port)
+{
+ struct mlx4_priv *priv = mlx4_priv(dev);
+ u8 random_mac[6];
+ char *raw_gid;
+
+ /* hw GUID */
+ if (entry == 0)
+ return;
+
+ eth_random_addr(random_mac);
+ raw_gid = (char *)&priv->mfunc.master.vf_admin[entry].vport[port].guid;
+ raw_gid[0] = random_mac[0] ^ 2;
+ raw_gid[1] = random_mac[1];
+ raw_gid[2] = random_mac[2];
+ raw_gid[3] = 0xff;
+ raw_gid[4] = 0xfe;
+ raw_gid[5] = random_mac[3];
+ raw_gid[6] = random_mac[4];
+ raw_gid[7] = random_mac[5];
+}
+
static int mlx4_setup_hca(struct mlx4_dev *dev)
{
struct mlx4_priv *priv = mlx4_priv(dev);
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 5c67bf0..f867d25 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -1340,6 +1340,7 @@ void mlx4_counter_free(struct mlx4_dev *dev, u32 idx);
void mlx4_set_admin_guid(struct mlx4_dev *dev, __be64 guid, int entry,
int port);
__be64 mlx4_get_admin_guid(struct mlx4_dev *dev, int entry, int port);
+void mlx4_set_random_admin_guid(struct mlx4_dev *dev, int entry, int port);
int mlx4_flow_attach(struct mlx4_dev *dev,
struct mlx4_net_trans_rule *rule, u64 *reg_id);
int mlx4_flow_detach(struct mlx4_dev *dev, u64 reg_id);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
