[PATCH rdma-next V1 0/8] Introduce vector CALC support

[PATCH rdma-next V1 0/8] Introduce vector CALC support

[Leon Romanovsky]

From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

This patch set introduces vector CALC support.

This feature takes as input several vectors of equal length,
combines them with a single operation type, producing result vectors
which are sent to the destination.

The proposed operations are "add, and, or, xor, max, min" and "swap
endianness".

The hardware processes the data an MTU of at a time, processing the elements
of each segment in parallel.

This patch set depends on commit b4ff3a36d3e4 ("net/mlx5: Use offset based
reserved field names in the IFC header file") which is part of net tree.

The series consists from two parts: IB and net.

NET part (patches #1-3)
* Patch #1 fixes ATOMIC capability mode. This change has  no impact on
* the system, since MAX property is not in use for ATOMIC.
* Patch #2 merges two device capability calls in one.
* Patch #3 adds infrastructure to support vector CALC querying.

IB part (patches #4-8)
* Patch #4 refactors device query code by eliminating the unnecessary zeroing
  of variables
* Patch #5 converts device capability mask from u32 to be u64 and support more
  than 32 device capabilities.
* Patch #6 adds vector CALC device capability flag.
* Patch #7 exports all possible supported operations.
* Patch #8 advertises the mlx5 driver support of vector CALC.

Changes since v0:
- Fixed author part of patch #3
- Updated hca_cap field in ipoib to be u64 and not u32.
- Enrich commit message of patch #7

Leon Romanovsky (7):
  net/mlx5_core: Fix caching ATOMIC endian mode capability
  net/mlx5_core: Refactor device capability function
  IB/core: Replace setting the zero values in ib_uverbs_ex_query_device
  IB/{core,ulp} Support above 32 possible device capability flags
  IB/core: Add offload arithmetic operations support
  IB/core: Advertise supported vector CALC capabilities
  IB/mlx5: Exposure offload arithmetic operations

Sagi Grimberg (1):
  net/mlx5_core: Introduce offload arithmetic hardware capabilities

 drivers/infiniband/core/uverbs_cmd.c           | 29 +++++++------
 drivers/infiniband/hw/mlx5/main.c              |  3 ++
 drivers/infiniband/ulp/ipoib/ipoib.h           |  2 +-
 drivers/net/ethernet/mellanox/mlx5/core/fw.c   | 57 ++++++--------------------
 drivers/net/ethernet/mellanox/mlx5/core/main.c | 24 +++++++----
 include/linux/mlx5/device.h                    |  6 +++
 include/linux/mlx5/driver.h                    |  3 +-
 include/linux/mlx5/mlx5_ifc.h                  | 31 +++++++++++++-
 include/rdma/ib_verbs.h                        | 29 ++++++++++++-
 include/uapi/rdma/ib_user_verbs.h              | 13 ++++++
 10 files changed, 124 insertions(+), 73 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH rdma-next V1 1/8] net/mlx5_core: Fix caching ATOMIC endian mode capability

[Leon Romanovsky]

From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

Add caching of maximum device capability of ATOMIC endian mode.

Fixes: f91e6d8941bf ('net/mlx5_core: Add setting ATOMIC endian mode')
Signed-off-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 1545a94..b86fe50 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -423,6 +423,10 @@ static int handle_hca_cap_atomic(struct mlx5_core_dev *dev)
 					 HCA_CAP_OPMOD_GET_CUR);
 		if (err)
 			return err;
+		err = mlx5_core_get_caps(dev, MLX5_CAP_ATOMIC,
+					 HCA_CAP_OPMOD_GET_MAX);
+		if (err)
+			return err;
 	} else {
 		return 0;
 	}
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH rdma-next V1 2/8] net/mlx5_core: Refactor device capability function

[Leon Romanovsky]

From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

Device capability function was called similar in all places.
It was called twice for every queried parameter, while the
difference between calls was in HCA capability mode only.

The change proposed unify these calls into one function.

Signed-off-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/net/ethernet/mellanox/mlx5/core/fw.c   | 55 ++++----------------------
 drivers/net/ethernet/mellanox/mlx5/core/main.c | 28 +++++++------
 include/linux/mlx5/driver.h                    |  3 +-
 3 files changed, 24 insertions(+), 62 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fw.c b/drivers/net/ethernet/mellanox/mlx5/core/fw.c
index aa1ab47..fe6dfd8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fw.c
@@ -98,88 +98,49 @@ int mlx5_query_hca_caps(struct mlx5_core_dev *dev)
 {
 	int err;
 
-	err = mlx5_core_get_caps(dev, MLX5_CAP_GENERAL, HCA_CAP_OPMOD_GET_CUR);
-	if (err)
-		return err;
-
-	err = mlx5_core_get_caps(dev, MLX5_CAP_GENERAL, HCA_CAP_OPMOD_GET_MAX);
+	err = mlx5_core_get_caps(dev, MLX5_CAP_GENERAL);
 	if (err)
 		return err;
 
 	if (MLX5_CAP_GEN(dev, eth_net_offloads)) {
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ETHERNET_OFFLOADS,
-					 HCA_CAP_OPMOD_GET_CUR);
-		if (err)
-			return err;
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ETHERNET_OFFLOADS,
-					 HCA_CAP_OPMOD_GET_MAX);
+		err = mlx5_core_get_caps(dev, MLX5_CAP_ETHERNET_OFFLOADS);
 		if (err)
 			return err;
 	}
 
 	if (MLX5_CAP_GEN(dev, pg)) {
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ODP,
-					 HCA_CAP_OPMOD_GET_CUR);
-		if (err)
-			return err;
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ODP,
-					 HCA_CAP_OPMOD_GET_MAX);
+		err = mlx5_core_get_caps(dev, MLX5_CAP_ODP);
 		if (err)
 			return err;
 	}
 
 	if (MLX5_CAP_GEN(dev, atomic)) {
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ATOMIC,
-					 HCA_CAP_OPMOD_GET_CUR);
-		if (err)
-			return err;
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ATOMIC,
-					 HCA_CAP_OPMOD_GET_MAX);
+		err = mlx5_core_get_caps(dev, MLX5_CAP_ATOMIC);
 		if (err)
 			return err;
 	}
 
 	if (MLX5_CAP_GEN(dev, roce)) {
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ROCE,
-					 HCA_CAP_OPMOD_GET_CUR);
-		if (err)
-			return err;
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ROCE,
-					 HCA_CAP_OPMOD_GET_MAX);
+		err = mlx5_core_get_caps(dev, MLX5_CAP_ROCE);
 		if (err)
 			return err;
 	}
 
 	if (MLX5_CAP_GEN(dev, nic_flow_table)) {
-		err = mlx5_core_get_caps(dev, MLX5_CAP_FLOW_TABLE,
-					 HCA_CAP_OPMOD_GET_CUR);
-		if (err)
-			return err;
-		err = mlx5_core_get_caps(dev, MLX5_CAP_FLOW_TABLE,
-					 HCA_CAP_OPMOD_GET_MAX);
+		err = mlx5_core_get_caps(dev, MLX5_CAP_FLOW_TABLE);
 		if (err)
 			return err;
 	}
 
 	if (MLX5_CAP_GEN(dev, vport_group_manager) &&
 	    MLX5_CAP_GEN(dev, eswitch_flow_table)) {
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ESWITCH_FLOW_TABLE,
-					 HCA_CAP_OPMOD_GET_CUR);
-		if (err)
-			return err;
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ESWITCH_FLOW_TABLE,
-					 HCA_CAP_OPMOD_GET_MAX);
+		err = mlx5_core_get_caps(dev, MLX5_CAP_ESWITCH_FLOW_TABLE);
 		if (err)
 			return err;
 	}
 
 	if (MLX5_CAP_GEN(dev, eswitch_flow_table)) {
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ESWITCH,
-					 HCA_CAP_OPMOD_GET_CUR);
-		if (err)
-			return err;
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ESWITCH,
-					 HCA_CAP_OPMOD_GET_MAX);
+		err = mlx5_core_get_caps(dev, MLX5_CAP_ESWITCH);
 		if (err)
 			return err;
 	}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index b86fe50..9397768 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -341,8 +341,9 @@ static u16 to_fw_pkey_sz(u32 size)
 	}
 }
 
-int mlx5_core_get_caps(struct mlx5_core_dev *dev, enum mlx5_cap_type cap_type,
-		       enum mlx5_cap_mode cap_mode)
+static int mlx5_core_get_caps_mode(struct mlx5_core_dev *dev,
+				   enum mlx5_cap_type cap_type,
+				   enum mlx5_cap_mode cap_mode)
 {
 	u8 in[MLX5_ST_SZ_BYTES(query_hca_cap_in)];
 	int out_sz = MLX5_ST_SZ_BYTES(query_hca_cap_out);
@@ -392,6 +393,16 @@ query_ex:
 	return err;
 }
 
+int mlx5_core_get_caps(struct mlx5_core_dev *dev, enum mlx5_cap_type cap_type)
+{
+	int ret;
+
+	ret = mlx5_core_get_caps_mode(dev, cap_type, HCA_CAP_OPMOD_GET_CUR);
+	if (ret)
+		return ret;
+	return mlx5_core_get_caps_mode(dev, cap_type, HCA_CAP_OPMOD_GET_MAX);
+}
+
 static int set_caps(struct mlx5_core_dev *dev, void *in, int in_sz, int opmod)
 {
 	u32 out[MLX5_ST_SZ_DW(set_hca_cap_out)];
@@ -419,12 +430,7 @@ static int handle_hca_cap_atomic(struct mlx5_core_dev *dev)
 	int err;
 
 	if (MLX5_CAP_GEN(dev, atomic)) {
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ATOMIC,
-					 HCA_CAP_OPMOD_GET_CUR);
-		if (err)
-			return err;
-		err = mlx5_core_get_caps(dev, MLX5_CAP_ATOMIC,
-					 HCA_CAP_OPMOD_GET_MAX);
+		err = mlx5_core_get_caps(dev, MLX5_CAP_ATOMIC);
 		if (err)
 			return err;
 	} else {
@@ -466,11 +472,7 @@ static int handle_hca_cap(struct mlx5_core_dev *dev)
 	if (!set_ctx)
 		goto query_ex;
 
-	err = mlx5_core_get_caps(dev, MLX5_CAP_GENERAL, HCA_CAP_OPMOD_GET_MAX);
-	if (err)
-		goto query_ex;
-
-	err = mlx5_core_get_caps(dev, MLX5_CAP_GENERAL, HCA_CAP_OPMOD_GET_CUR);
+	err = mlx5_core_get_caps(dev, MLX5_CAP_GENERAL);
 	if (err)
 		goto query_ex;
 
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index 1e3006d..1f1d971 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -706,8 +706,7 @@ void mlx5_cmd_use_events(struct mlx5_core_dev *dev);
 void mlx5_cmd_use_polling(struct mlx5_core_dev *dev);
 int mlx5_cmd_status_to_err(struct mlx5_outbox_hdr *hdr);
 int mlx5_cmd_status_to_err_v2(void *ptr);
-int mlx5_core_get_caps(struct mlx5_core_dev *dev, enum mlx5_cap_type cap_type,
-		       enum mlx5_cap_mode cap_mode);
+int mlx5_core_get_caps(struct mlx5_core_dev *dev, enum mlx5_cap_type cap_type);
 int mlx5_cmd_exec(struct mlx5_core_dev *dev, void *in, int in_size, void *out,
 		  int out_size);
 int mlx5_cmd_exec_cb(struct mlx5_core_dev *dev, void *in, int in_size,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH rdma-next V1 3/8] net/mlx5_core: Introduce offload arithmetic hardware capabilities

[Leon Romanovsky]

From: Sagi Grimberg <sagig-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

Define the necessary hardware structures for the offload
arithmetic capabilities and read/cache them on driver load.

Signed-off-by: Sagi Grimberg <sagig-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/net/ethernet/mellanox/mlx5/core/fw.c |  6 ++++++
 include/linux/mlx5/device.h                  |  6 ++++++
 include/linux/mlx5/mlx5_ifc.h                | 31 +++++++++++++++++++++++++++-
 3 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fw.c b/drivers/net/ethernet/mellanox/mlx5/core/fw.c
index fe6dfd8..75c7ae6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fw.c
@@ -145,6 +145,12 @@ int mlx5_query_hca_caps(struct mlx5_core_dev *dev)
 			return err;
 	}
 
+	if (MLX5_CAP_GEN(dev, vector_calc)) {
+		err = mlx5_core_get_caps(dev, MLX5_CAP_VECTOR_CALC);
+		if (err)
+			return err;
+	}
+
 	return 0;
 }
 
diff --git a/include/linux/mlx5/device.h b/include/linux/mlx5/device.h
index 987764a..1f2cedf 100644
--- a/include/linux/mlx5/device.h
+++ b/include/linux/mlx5/device.h
@@ -1196,6 +1196,8 @@ enum mlx5_cap_type {
 	MLX5_CAP_FLOW_TABLE,
 	MLX5_CAP_ESWITCH_FLOW_TABLE,
 	MLX5_CAP_ESWITCH,
+	MLX5_CAP_RESERVED,
+	MLX5_CAP_VECTOR_CALC,
 	/* NUM OF CAP Types */
 	MLX5_CAP_NUM
 };
@@ -1258,6 +1260,10 @@ enum mlx5_cap_type {
 #define MLX5_CAP_ODP(mdev, cap)\
 	MLX5_GET(odp_cap, mdev->hca_caps_cur[MLX5_CAP_ODP], cap)
 
+#define MLX5_CAP_VECTOR_CALC(mdev, cap) \
+	MLX5_GET(vector_calc_cap, \
+		 mdev->hca_caps_cur[MLX5_CAP_VECTOR_CALC], cap)
+
 enum {
 	MLX5_CMD_STAT_OK			= 0x0,
 	MLX5_CMD_STAT_INT_ERR			= 0x1,
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 455d9cc..d34ad50 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -617,6 +617,33 @@ struct mlx5_ifc_odp_cap_bits {
 	u8         reserved_at_80[0x720];
 };
 
+struct mlx5_ifc_calc_op {
+	u8        reserved_at_0[0x10];
+	u8        reserved_at_10[0x9];
+	u8        op_swap_endianness[0x1];
+	u8        op_min[0x1];
+	u8        op_xor[0x1];
+	u8        op_or[0x1];
+	u8        op_and[0x1];
+	u8        op_max[0x1];
+	u8        op_add[0x1];
+};
+
+struct mlx5_ifc_vector_calc_cap_bits {
+	u8         calc_matrix[0x1];
+	u8         reserved_at_1[0x1f];
+	u8         reserved_at_20[0x8];
+	u8         max_vec_count[0x8];
+	u8         reserved_at_30[0xd];
+	u8         max_chunk_size[0x3];
+	struct mlx5_ifc_calc_op calc0;
+	struct mlx5_ifc_calc_op calc1;
+	struct mlx5_ifc_calc_op calc2;
+	struct mlx5_ifc_calc_op calc3;
+
+	u8         reserved_at_e0[0x720];
+};
+
 enum {
 	MLX5_WQ_TYPE_LINKED_LIST  = 0x0,
 	MLX5_WQ_TYPE_CYCLIC       = 0x1,
@@ -781,7 +808,8 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         cd[0x1];
 	u8         reserved_at_22c[0x1];
 	u8         apm[0x1];
-	u8         reserved_at_22e[0x7];
+	u8         vector_calc[0x1];
+	u8         reserved_at_22f[0x6];
 	u8         qkv[0x1];
 	u8         pkv[0x1];
 	u8         reserved_at_237[0x4];
@@ -1918,6 +1946,7 @@ union mlx5_ifc_hca_cap_union_bits {
 	struct mlx5_ifc_flow_table_nic_cap_bits flow_table_nic_cap;
 	struct mlx5_ifc_flow_table_eswitch_cap_bits flow_table_eswitch_cap;
 	struct mlx5_ifc_e_switch_cap_bits e_switch_cap;
+	struct mlx5_ifc_vector_calc_cap_bits vector_calc_cap;
 	u8         reserved_at_0[0x8000];
 };
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH rdma-next V1 4/8] IB/core: Replace setting the zero values in ib_uverbs_ex_query_device

[Leon Romanovsky]

From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

The setting to zero during variable initialization eliminates
the need to explicitly set to zero variables and structures.

Signed-off-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/infiniband/core/uverbs_cmd.c | 15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/infiniband/core/uverbs_cmd.c b/drivers/infiniband/core/uverbs_cmd.c
index 6ffc9c4..c647d67 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -3583,9 +3583,9 @@ int ib_uverbs_ex_query_device(struct ib_uverbs_file *file,
 			      struct ib_udata *ucore,
 			      struct ib_udata *uhw)
 {
-	struct ib_uverbs_ex_query_device_resp resp;
+	struct ib_uverbs_ex_query_device_resp resp = { {0} };
 	struct ib_uverbs_ex_query_device  cmd;
-	struct ib_device_attr attr;
+	struct ib_device_attr attr = {0};
 	int err;
 
 	if (ucore->inlen < sizeof(cmd))
@@ -3606,14 +3606,11 @@ int ib_uverbs_ex_query_device(struct ib_uverbs_file *file,
 	if (ucore->outlen < resp.response_length)
 		return -ENOSPC;
 
-	memset(&attr, 0, sizeof(attr));
-
 	err = ib_dev->query_device(ib_dev, &attr, uhw);
 	if (err)
 		return err;
 
 	copy_query_dev_fields(file, ib_dev, &resp.base, &attr);
-	resp.comp_mask = 0;
 
 	if (ucore->outlen < resp.response_length + sizeof(resp.odp_caps))
 		goto end;
@@ -3626,9 +3623,6 @@ int ib_uverbs_ex_query_device(struct ib_uverbs_file *file,
 		attr.odp_caps.per_transport_caps.uc_odp_caps;
 	resp.odp_caps.per_transport_caps.ud_odp_caps =
 		attr.odp_caps.per_transport_caps.ud_odp_caps;
-	resp.odp_caps.reserved = 0;
-#else
-	memset(&resp.odp_caps, 0, sizeof(resp.odp_caps));
 #endif
 	resp.response_length += sizeof(resp.odp_caps);
 
@@ -3646,8 +3640,5 @@ int ib_uverbs_ex_query_device(struct ib_uverbs_file *file,
 
 end:
 	err = ib_copy_to_udata(ucore, &resp, resp.response_length);
-	if (err)
-		return err;
-
-	return 0;
+	return err;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH rdma-next V1 5/8] IB/{core,ulp} Support above 32 possible device capability flags

[Leon Romanovsky]

From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

The old bitwise device_cap_flags variable was limited to u32 which
has all bits already defined. In order to overcome it, we converted
device_cap_flags variable to be u64 type.

Signed-off-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/infiniband/core/uverbs_cmd.c | 2 +-
 drivers/infiniband/ulp/ipoib/ipoib.h | 2 +-
 include/rdma/ib_verbs.h              | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/core/uverbs_cmd.c b/drivers/infiniband/core/uverbs_cmd.c
index c647d67..6887252 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -402,7 +402,7 @@ static void copy_query_dev_fields(struct ib_uverbs_file *file,
 	resp->hw_ver		= attr->hw_ver;
 	resp->max_qp		= attr->max_qp;
 	resp->max_qp_wr		= attr->max_qp_wr;
-	resp->device_cap_flags	= attr->device_cap_flags;
+	resp->device_cap_flags	= lower_32_bits(attr->device_cap_flags);
 	resp->max_sge		= attr->max_sge;
 	resp->max_sge_rd	= attr->max_sge_rd;
 	resp->max_cq		= attr->max_cq;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index a6f3eab..4dd05f0 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -387,7 +387,7 @@ struct ipoib_dev_priv {
 	struct dentry *mcg_dentry;
 	struct dentry *path_dentry;
 #endif
-	int	hca_caps;
+	u64	hca_caps;
 	struct ipoib_ethtool_st ethtool;
 	struct timer_list poll_timer;
 };
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 284b00c..2ff1fd1 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -273,7 +273,7 @@ struct ib_device_attr {
 	u32			hw_ver;
 	int			max_qp;
 	int			max_qp_wr;
-	int			device_cap_flags;
+	u64			device_cap_flags;
 	int			max_sge;
 	int			max_sge_rd;
 	int			max_cq;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH rdma-next V1 6/8] IB/core: Add offload arithmetic operations support

[Leon Romanovsky]

From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

The offload arithmetic operations support allows to the user to
benefit from the parallel calculation of several input vectors of
equal length.

The newly added flag indicates this ability.

Signed-off-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/infiniband/core/uverbs_cmd.c | 3 +++
 include/rdma/ib_verbs.h              | 8 +++++++-
 include/uapi/rdma/ib_user_verbs.h    | 5 +++++
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/uverbs_cmd.c b/drivers/infiniband/core/uverbs_cmd.c
index 6887252..3a3f573 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -3638,6 +3638,9 @@ int ib_uverbs_ex_query_device(struct ib_uverbs_file *file,
 	resp.hca_core_clock = attr.hca_core_clock;
 	resp.response_length += sizeof(resp.hca_core_clock);
 
+	resp.device_cap_flags2 = upper_32_bits(attr.device_cap_flags);
+	resp.response_length += sizeof(resp.device_cap_flags2);
+
 end:
 	err = ib_copy_to_udata(ucore, &resp, resp.response_length);
 	return err;
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 2ff1fd1..51aabf8 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -208,10 +208,16 @@ enum ib_device_cap_flags {
 	 * of I/O operations with single completion queue managed
 	 * by hardware.
 	 */
-	IB_DEVICE_CROSS_CHANNEL		= (1 << 27),
+	IB_DEVICE_CROSS_CHANNEL			= (1 << 27),
 	IB_DEVICE_MANAGED_FLOW_STEERING		= (1 << 29),
 	IB_DEVICE_SIGNATURE_HANDOVER		= (1 << 30),
 	IB_DEVICE_ON_DEMAND_PAGING		= (1 << 31),
+	/*
+	 * The offload arithmetic operations support allows to
+	 * the user to benefit from the parallel calculation of
+	 * several input vectors of equal length.
+	 */
+	IB_DEVICE_VECTOR_CALC                   = (1ULL << 32),
 };
 
 enum ib_signature_prot_cap {
diff --git a/include/uapi/rdma/ib_user_verbs.h b/include/uapi/rdma/ib_user_verbs.h
index 8126c14..e024c82 100644
--- a/include/uapi/rdma/ib_user_verbs.h
+++ b/include/uapi/rdma/ib_user_verbs.h
@@ -226,6 +226,11 @@ struct ib_uverbs_ex_query_device_resp {
 	struct ib_uverbs_odp_caps odp_caps;
 	__u64 timestamp_mask;
 	__u64 hca_core_clock; /* in KHZ */
+	/*
+	 * Original capability field is limited
+	 * by __u32 variable.  Need to increase this field
+	 */
+	__u64 device_cap_flags2;
 };
 
 struct ib_uverbs_query_port {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH rdma-next V1 7/8] IB/core: Advertise supported vector CALC capabilities

[Leon Romanovsky]

From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

This vector CALC feature allows different offloaded arithmetic
calculations of several vectors of equal length.

In order to properly use this feature, the user space applications
need to know the supported properties, like operations, size and
maximal number of vectors.

The properties exposed are:
* calc_matrix - If set, vector CALC matrix is supported.
* max_vector_count - Maximum number of vectors supported.
* max_chunk_size - Maximum chunk size supported.
* op_cap - Bit mask indicates which vector CALC operations are supported:
	Bit 1: ADD operation
	Bit 2: MAX operation
	Bit 3: AND operation
	Bit 4: OR operation
	Bit 5: XOR operation
	Bit 6: MIN operation
	Bit 7: SWAP_ENDIANNESS operation

This change returns vector CALC supported properties to the caller.

Signed-off-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/infiniband/core/uverbs_cmd.c |  9 +++++++++
 include/rdma/ib_verbs.h              | 19 +++++++++++++++++++
 include/uapi/rdma/ib_user_verbs.h    |  8 ++++++++
 3 files changed, 36 insertions(+)

diff --git a/drivers/infiniband/core/uverbs_cmd.c b/drivers/infiniband/core/uverbs_cmd.c
index 3a3f573..3618ca5 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -3641,6 +3641,15 @@ int ib_uverbs_ex_query_device(struct ib_uverbs_file *file,
 	resp.device_cap_flags2 = upper_32_bits(attr.device_cap_flags);
 	resp.response_length += sizeof(resp.device_cap_flags2);
 
+	if (ucore->outlen < resp.response_length + sizeof(resp.calc_caps))
+		goto end;
+
+	resp.calc_caps.calc_matrix = attr.calc_caps.calc_matrix;
+	resp.calc_caps.max_vector_count = attr.calc_caps.max_vector_count;
+	resp.calc_caps.max_chunk_size = attr.calc_caps.max_chunk_size;
+	resp.calc_caps.op_cap = attr.calc_caps.op_cap;
+	resp.response_length += sizeof(resp.calc_caps);
+
 end:
 	err = ib_copy_to_udata(ucore, &resp, resp.response_length);
 	return err;
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 51aabf8..1f74ebb 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -258,6 +258,24 @@ struct ib_odp_caps {
 	} per_transport_caps;
 };
 
+enum ib_calc_operations {
+	IB_CALC_NONE,
+	IB_CALC_ADD,
+	IB_CALC_MAX,
+	IB_CALC_AND,
+	IB_CALC_OR,
+	IB_CALC_XOR,
+	IB_CALC_MIN,
+	IB_CALC_SWAP_ENDIANNESS
+};
+
+struct ib_calc_caps {
+	u32	calc_matrix;
+	u32	max_vector_count;
+	u32	max_chunk_size;
+	u32	op_cap;
+};
+
 enum ib_cq_creation_flags {
 	IB_CQ_FLAGS_TIMESTAMP_COMPLETION   = 1 << 0,
 	IB_CQ_FLAGS_IGNORE_OVERRUN	   = 1 << 1,
@@ -315,6 +333,7 @@ struct ib_device_attr {
 	struct ib_odp_caps	odp_caps;
 	uint64_t		timestamp_mask;
 	uint64_t		hca_core_clock; /* in KHZ */
+	struct ib_calc_caps	calc_caps;
 };
 
 enum ib_mtu {
diff --git a/include/uapi/rdma/ib_user_verbs.h b/include/uapi/rdma/ib_user_verbs.h
index e024c82..c88d8e2 100644
--- a/include/uapi/rdma/ib_user_verbs.h
+++ b/include/uapi/rdma/ib_user_verbs.h
@@ -219,6 +219,13 @@ struct ib_uverbs_odp_caps {
 	__u32 reserved;
 };
 
+struct ib_uverbs_calc_caps {
+	__u32	calc_matrix;
+	__u32	max_vector_count;
+	__u32	max_chunk_size;
+	__u32	op_cap;
+};
+
 struct ib_uverbs_ex_query_device_resp {
 	struct ib_uverbs_query_device_resp base;
 	__u32 comp_mask;
@@ -231,6 +238,7 @@ struct ib_uverbs_ex_query_device_resp {
 	 * by __u32 variable.  Need to increase this field
 	 */
 	__u64 device_cap_flags2;
+	struct ib_uverbs_calc_caps calc_caps;
 };
 
 struct ib_uverbs_query_port {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rdma-next V1 7/8] IB/core: Advertise supported vector CALC capabilities

[Jason Gunthorpe]

On Tue, Feb 23, 2016 at 10:25:27AM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> 
> This vector CALC feature allows different offloaded arithmetic
> calculations of several vectors of equal length.
> 
> In order to properly use this feature, the user space applications
> need to know the supported properties, like operations, size and
> maximal number of vectors.
> 
> The properties exposed are:
> * calc_matrix - If set, vector CALC matrix is supported.
> * max_vector_count - Maximum number of vectors supported.
> * max_chunk_size - Maximum chunk size supported.

This kind of stuff should be in a kdoc not lost in a commit message.

> * op_cap - Bit mask indicates which vector CALC operations are supported:
> 	Bit 1: ADD operation
> 	Bit 2: MAX operation
> 	Bit 3: AND operation
> 	Bit 4: OR operation
> 	Bit 5: XOR operation
> 	Bit 6: MIN operation
> 	Bit 7: SWAP_ENDIANNESS operation

This should be constants in the uAPI header.

A commit message is not documentation.

Can you defend why this proprietary extension is being shoved into the
common uapi and not dumped in the vendor area? Is an IBTA
standardization forthcoming? Have you collaborated with other vendors
to agree on this API?

I really agree with Christoph Hellwig, this continuous churn on the
common api for non-standard features is really bad. We need to have a
higher bar for acceptance, which is something stronger than one vendor
implementing something in their hardware.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rdma-next V1 7/8] IB/core: Advertise supported vector CALC capabilities

[Sagi Grimberg]

Hi Jason,

>> The properties exposed are:
>> * calc_matrix - If set, vector CALC matrix is supported.
>> * max_vector_count - Maximum number of vectors supported.
>> * max_chunk_size - Maximum chunk size supported.
>
> This kind of stuff should be in a kdoc not lost in a commit message.

I agree.

>> * op_cap - Bit mask indicates which vector CALC operations are supported:
>> 	Bit 1: ADD operation
>> 	Bit 2: MAX operation
>> 	Bit 3: AND operation
>> 	Bit 4: OR operation
>> 	Bit 5: XOR operation
>> 	Bit 6: MIN operation
>> 	Bit 7: SWAP_ENDIANNESS operation
>
> This should be constants in the uAPI header.
>
> A commit message is not documentation.

Agree here too.

> Can you defend why this proprietary extension is being shoved into the
> common uapi and not dumped in the vendor area? Is an IBTA
> standardization forthcoming? Have you collaborated with other vendors
> to agree on this API?
>
> I really agree with Christoph Hellwig, this continuous churn on the
> common api for non-standard features is really bad. We need to have a
> higher bar for acceptance, which is something stronger than one vendor
> implementing something in their hardware.

I also agree with Christoph, however I don't know if we should require
IBTA standardization for each feature we add to our ibverbs. This
feature introduces application specific offloads, there are no wire
protocol implications. It's a question of view I guess, my view is
that we want to get our verbs closer to what applications want rather
then restricting it to be a messaging API, we just need to make sure
that the API fits the application requirements.

I think that it's the community's job to decide if this is a) useful
and b) exposed and implemented correctly. This patchset is exactly a
collaboration with other vendors to agree on the API.

And I honestly don't understand the "one vendor" complaint. It's really
hard to make progress this way? Yes, one vendor introduces a feature,
it's always the case. Do we need to wait for others to do it too for it
to make upstream? If a feature is useful and exposed correctly there is
nothing stopping other vendors to do it too (given that the API is
not tied to a vendor implementation).

Generally speaking, I'm confident that all the smart people on
Linux-rdma can converge on suitable APIs that are actually useful,
maintainable and don't impose a single vendor implementation. Leon,
Or, Matan and others are more than willing to receive input from the
community.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rdma-next V1 7/8] IB/core: Advertise supported vector CALC capabilities

[Jason Gunthorpe]

On Wed, Mar 02, 2016 at 07:07:58PM +0200, Sagi Grimberg wrote:

> And I honestly don't understand the "one vendor" complaint. It's really
> hard to make progress this way? Yes, one vendor introduces a feature,
> it's always the case. Do we need to wait for others to do it too for it
> to make upstream? If a feature is useful and exposed correctly there is
> nothing stopping other vendors to do it too (given that the API is
> not tied to a vendor implementation).

I don't necessarily mean other vendors have to implement it, just sign
off on it.

We have the IBTA as a multi-vendor body that has historically defined
the verbs API. It would be appropriate if verbs changes were ack'd by
their SW-WG.

The OFA has talked about a 'verbs working group' (what happened to
that Liran?) that could also evolve into an appropriate place to get
such a sign off. It may be a more inclusive/neutral place these days
with so many non-IB verbs implementations.

> Generally speaking, I'm confident that all the smart people on
> Linux-rdma can converge on suitable APIs that are actually useful,

The thing is, I don't think the right people are necessarily reading
this list. There are now many vendors of verbs hardware out there, do
you really think posting to the list is enough to catch all of their
attention?

My concern is changes to verbs are very rarely a software only change
- there is almost always a hardware component and within the industry
cross-vendor hardware specifications are typically negotiated by trade
associations not the Linux Kernel mailing list.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rdma-next V1 7/8] IB/core: Advertise supported vector CALC capabilities

[Sagi Grimberg]

Hi Jason,

>> And I honestly don't understand the "one vendor" complaint. It's really
>> hard to make progress this way? Yes, one vendor introduces a feature,
>> it's always the case. Do we need to wait for others to do it too for it
>> to make upstream? If a feature is useful and exposed correctly there is
>> nothing stopping other vendors to do it too (given that the API is
>> not tied to a vendor implementation).
>
> I don't necessarily mean other vendors have to implement it, just sign
> off on it.
>
> We have the IBTA as a multi-vendor body that has historically defined
> the verbs API. It would be appropriate if verbs changes were ack'd by
> their SW-WG.

I think it did, I'll let Liran answer on that.

> The OFA has talked about a 'verbs working group' (what happened to
> that Liran?) that could also evolve into an appropriate place to get
> such a sign off. It may be a more inclusive/neutral place these days
> with so many non-IB verbs implementations.

I'll let Liran comment on this too, but I know for a fact that Liran is
setting these meetings on a weekly basis and the vast majority of the
features Mellanox send out are introduced there. I joined a few times
to talk about some of the kernel API changes we did lately and the
upcoming "erasure coding offload" feature in the storage space...

>> Generally speaking, I'm confident that all the smart people on
>> Linux-rdma can converge on suitable APIs that are actually useful,
>
> The thing is, I don't think the right people are necessarily reading
> this list. There are now many vendors of verbs hardware out there, do
> you really think posting to the list is enough to catch all of their
> attention?

Actually I disagree, our verbs API is evolving and I don't see a better
place to shape and build it other than Linux-rdma. A vendor that cares
about RDMA verbs API should listen to this list, participate in the
discussions (also the API related ones) and help in bug fixes and
maintenance. That's the best way vendors can promote their cause
(user-space or kernel).

> My concern is changes to verbs are very rarely a software only change
> - there is almost always a hardware component and within the industry
> cross-vendor hardware specifications are typically negotiated by trade
> associations not the Linux Kernel mailing list.

That's true, but almost all user-space management stuff are handled in
the kernel leaving user-space to either ask uverbs or the HW device
for a service.

Are you suggesting that new offload features that are proposed would
also introduce a SW implementation that can run on any device? That's
not a terrible idea, but it would be a lot of extra work and might
bloat our verbs library.

What do others think?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH rdma-next V1 7/8] IB/core: Advertise supported vector CALC capabilities

[Liran Liss]

> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Jason Gunthorpe

> 
> The OFA has talked about a 'verbs working group' (what happened to that
> Liran?) that could also evolve into an appropriate place to get such a sign off. It
> may be a more inclusive/neutral place these days with so many non-IB verbs
> implementations.
> 

The Verbs working group has been meeting twice a month since its inception to discuss such emerging features and new concepts.
--Liran
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rdma-next V1 7/8] IB/core: Advertise supported vector CALC capabilities

[Leon Romanovsky]

On Tue, Feb 23, 2016 at 11:44:00AM -0700, Jason Gunthorpe wrote:
> On Tue, Feb 23, 2016 at 10:25:27AM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > 
> > This vector CALC feature allows different offloaded arithmetic
> > calculations of several vectors of equal length.
> > 
> > In order to properly use this feature, the user space applications
> > need to know the supported properties, like operations, size and
> > maximal number of vectors.
> > 
> > The properties exposed are:
> > * calc_matrix - If set, vector CALC matrix is supported.
> > * max_vector_count - Maximum number of vectors supported.
> > * max_chunk_size - Maximum chunk size supported.
> 
> This kind of stuff should be in a kdoc not lost in a commit message.
> 
> > * op_cap - Bit mask indicates which vector CALC operations are supported:
> > 	Bit 1: ADD operation
> > 	Bit 2: MAX operation
> > 	Bit 3: AND operation
> > 	Bit 4: OR operation
> > 	Bit 5: XOR operation
> > 	Bit 6: MIN operation
> > 	Bit 7: SWAP_ENDIANNESS operation
> 
> This should be constants in the uAPI header.
> 
> A commit message is not documentation.

Sorry for not actively participating in this discussion, I was
traveling with terrible internet access.

I'll be more than happy to send the version with your concerns fixed.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH rdma-next V1 8/8] IB/mlx5: Exposure offload arithmetic operations

[Leon Romanovsky]

From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

Advertise the offload arithmetic operations support.

Signed-off-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/infiniband/hw/mlx5/main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index 03c418c..9e92f48 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -549,6 +549,9 @@ static int mlx5_ib_query_device(struct ib_device *ibdev,
 	if (MLX5_CAP_GEN(mdev, cd))
 		props->device_cap_flags |= IB_DEVICE_CROSS_CHANNEL;
 
+	if (MLX5_CAP_GEN(dev->mdev, vector_calc))
+		props->device_cap_flags |= IB_DEVICE_VECTOR_CALC;
+
 	return 0;
 }
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH rdma-next V1 0/8] Introduce vector CALC support

[Steve Wise]

> -----Original Message-----
> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Leon Romanovsky
> Sent: Tuesday, February 23, 2016 2:25 AM
> To: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org
> Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Leon Romanovsky
> Subject: [PATCH rdma-next V1 0/8] Introduce vector CALC support
> 
> From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> 
> This patch set introduces vector CALC support.
> 
> This feature takes as input several vectors of equal length,
> combines them with a single operation type, producing result vectors
> which are sent to the destination.
> 
> The proposed operations are "add, and, or, xor, max, min" and "swap
> endianness".
> 
> The hardware processes the data an MTU of at a time, processing the elements
> of each segment in parallel.
> 
> This patch set depends on commit b4ff3a36d3e4 ("net/mlx5: Use offset based
> reserved field names in the IFC header file") which is part of net tree.
> 

Hey Leon,

I look through this and I don't see any user of this.  I also don't see any API for submitting these operations.  Did I miss
something?  It looks like this series just cleans up some code and adds the ability to advertise CALC.  Where's the user(s)?

Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rdma-next V1 0/8] Introduce vector CALC support

[Leon Romanovsky]

On Tue, Feb 23, 2016 at 5:28 PM, Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> wrote:
>
>
>> -----Original Message-----
>> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Leon Romanovsky
>> Sent: Tuesday, February 23, 2016 2:25 AM
>> To: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org
>> Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Leon Romanovsky
>> Subject: [PATCH rdma-next V1 0/8] Introduce vector CALC support
>>
>> From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>
>> This patch set introduces vector CALC support.
>>
>> This feature takes as input several vectors of equal length,
>> combines them with a single operation type, producing result vectors
>> which are sent to the destination.
>>
>> The proposed operations are "add, and, or, xor, max, min" and "swap
>> endianness".
>>
>> The hardware processes the data an MTU of at a time, processing the elements
>> of each segment in parallel.
>>
>> This patch set depends on commit b4ff3a36d3e4 ("net/mlx5: Use offset based
>> reserved field names in the IFC header file") which is part of net tree.
>>
>
> Hey Leon,
>
> I look through this and I don't see any user of this.  I also don't see any API for submitting these operations.  Did I miss
> something?  It looks like this series just cleans up some code and adds the ability to advertise CALC.  Where's the user(s)?

The user will come in the following patches. I'll submit libibverbs
and libmlx5 supplementary parts right after I'll return to my office
from vacation.

Thanks.

>
> Steve
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rdma-next V1 0/8] Introduce vector CALC support

[Leon Romanovsky]

On Tue, Feb 23, 2016 at 10:25:20AM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> 
> NET part (patches #1-3)
> * Patch #1 fixes ATOMIC capability mode. This change has  no impact on
> * the system, since MAX property is not in use for ATOMIC.
> * Patch #2 merges two device capability calls in one.
> * Patch #3 adds infrastructure to support vector CALC querying.
> 
> IB part (patches #4-8)
> * Patch #4 refactors device query code by eliminating the unnecessary zeroing
>   of variables
> * Patch #5 converts device capability mask from u32 to be u64 and support more
>   than 32 device capabilities.

Hi Doug,
Is it possible to accept the patches #1-5 which fix and refactor
code only?

> * Patch #6 adds vector CALC device capability flag.
> * Patch #7 exports all possible supported operations.
> * Patch #8 advertises the mlx5 driver support of vector CALC.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rdma-next V1 0/8] Introduce vector CALC support

[Leon Romanovsky]

On Sun, Mar 06, 2016 at 12:45:08PM +0200, Leon Romanovsky wrote:
> On Tue, Feb 23, 2016 at 10:25:20AM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > 
> > NET part (patches #1-3)
> > * Patch #1 fixes ATOMIC capability mode. This change has  no impact on
> > * the system, since MAX property is not in use for ATOMIC.
> > * Patch #2 merges two device capability calls in one.
> > * Patch #3 adds infrastructure to support vector CALC querying.
> > 
> > IB part (patches #4-8)
> > * Patch #4 refactors device query code by eliminating the unnecessary zeroing
> >   of variables
> > * Patch #5 converts device capability mask from u32 to be u64 and support more
> >   than 32 device capabilities.
> 
> Hi Doug,
> Is it possible to accept the patches #1-5 which fix and refactor
> code only?

Hi Doug,
Your response will be greatly appreciated.

Thanks.

> 
> > * Patch #6 adds vector CALC device capability flag.
> > * Patch #7 exports all possible supported operations.
> > * Patch #8 advertises the mlx5 driver support of vector CALC.
> 
> Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rdma-next V1 0/8] Introduce vector CALC support

[Leon Romanovsky]

On Sat, Mar 12, 2016 at 12:17:24PM +0200, Leon Romanovsky wrote:
> On Sun, Mar 06, 2016 at 12:45:08PM +0200, Leon Romanovsky wrote:
> > On Tue, Feb 23, 2016 at 10:25:20AM +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > > 
> > > NET part (patches #1-3)
> > > * Patch #1 fixes ATOMIC capability mode. This change has  no impact on
> > > * the system, since MAX property is not in use for ATOMIC.
> > > * Patch #2 merges two device capability calls in one.
> > > * Patch #3 adds infrastructure to support vector CALC querying.
> > > 
> > > IB part (patches #4-8)
> > > * Patch #4 refactors device query code by eliminating the unnecessary zeroing
> > >   of variables
> > > * Patch #5 converts device capability mask from u32 to be u64 and support more
> > >   than 32 device capabilities.
> > 
> > Hi Doug,
> > Is it possible to accept the patches #1-5 which fix and refactor
> > code only?
> 
> Hi Doug,
> Your response will be greatly appreciated.

Hi Doug,
As a follow up to our phone conversation, the patches #1-5 has nothing
related to Vector CALC which is introduced in patch #6 only.

These patches perform simple refactoring and value extension which is
enough for Eli's SRIOV series.

The patches #6-8 will be respinned later with improved version of
Vector CALC.

Thanks.

> 
> > 
> > > * Patch #6 adds vector CALC device capability flag.
> > > * Patch #7 exports all possible supported operations.
> > > * Patch #8 advertises the mlx5 driver support of vector CALC.
> > 
> > Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rdma-next V1 0/8] Introduce vector CALC support

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

On 03/17/2016 10:48 AM, Leon Romanovsky wrote:
> On Sat, Mar 12, 2016 at 12:17:24PM +0200, Leon Romanovsky wrote:
>> On Sun, Mar 06, 2016 at 12:45:08PM +0200, Leon Romanovsky wrote:
>>> On Tue, Feb 23, 2016 at 10:25:20AM +0200, Leon Romanovsky wrote:
>>>> From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>>>
>>>> NET part (patches #1-3)
>>>> * Patch #1 fixes ATOMIC capability mode. This change has  no impact on
>>>> * the system, since MAX property is not in use for ATOMIC.
>>>> * Patch #2 merges two device capability calls in one.
>>>> * Patch #3 adds infrastructure to support vector CALC querying.
>>>>
>>>> IB part (patches #4-8)
>>>> * Patch #4 refactors device query code by eliminating the unnecessary zeroing
>>>>   of variables
>>>> * Patch #5 converts device capability mask from u32 to be u64 and support more
>>>>   than 32 device capabilities.
>>>
>>> Hi Doug,
>>> Is it possible to accept the patches #1-5 which fix and refactor
>>> code only?
>>
>> Hi Doug,
>> Your response will be greatly appreciated.
> 
> Hi Doug,
> As a follow up to our phone conversation, the patches #1-5 has nothing
> related to Vector CALC which is introduced in patch #6 only.
> 
> These patches perform simple refactoring and value extension which is
> enough for Eli's SRIOV series.
> 
> The patches #6-8 will be respinned later with improved version of
> Vector CALC.

Ok.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]