[PATCH for-next 0/2] mlx5_core: mlx5_ifc updates

[PATCH for-next 0/2] mlx5_core: mlx5_ifc updates

[Saeed Mahameed]

Hi Dave and Doug

This series include mlx5_core updates for both net-next and rdma
trees for 4.7 kernel cycle. This is the only shared code planned
for 4.7 between rdma and net trees. Hopefully, this will prevent 
future conflicts when merging between ib-next and net-next once
4.7 cycle is over and merge window is opened.

Both Mellanox rdma and net submissions will proceed once this series
is applied into both trees.

Future shared code will be sent to both maintainers as pull requests
from Mellanox's kernel.org tree.

We have included all the maintainers of respective drivers.
Kindly review the change and let us know in case of any review comments.

Saeed Mahameed (1):
  net/mlx5: Update mlx5_ifc hardware features

Tariq Toukan (1):
  net/mlx5: Fix mlx5 ifc cmd_hca_cap bad offsets

 include/linux/mlx5/mlx5_ifc.h |  253 +++++++++++++++++++++++++++++------------
 1 files changed, 179 insertions(+), 74 deletions(-)

--
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 for-next 1/2] net/mlx5: Fix mlx5 ifc cmd_hca_cap bad offsets

[Saeed Mahameed]

From: Tariq Toukan <tariqt@mellanox.com>

All reserved fields after early_vf_enable are off by 1, since
early_vf_enable was not explicitly declared as array of size 1.

Reserved field before cqe_zip had a wrong size, it should
be 0x80 + 0x3f.

Fixes: b0844444590e ("net/mlx5_core: Introduce access function to read internal timer ")
Fixes: b4ff3a36d3e4 ("net/mlx5: Use offset based reserved field names in the IFC header file")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Matan Barak <matanb@mellanox.com>
---
 include/linux/mlx5/mlx5_ifc.h |  107 +++++++++++++++++++++--------------------
 1 files changed, 55 insertions(+), 52 deletions(-)

diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index c15b8a8..c300e74 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -750,21 +750,21 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         ets[0x1];
 	u8         nic_flow_table[0x1];
 	u8         eswitch_flow_table[0x1];
-	u8	   early_vf_enable;
-	u8         reserved_at_1a8[0x2];
+	u8	   early_vf_enable[0x1];
+	u8         reserved_at_1a9[0x2];
 	u8         local_ca_ack_delay[0x5];
 	u8         reserved_at_1af[0x6];
 	u8         port_type[0x2];
 	u8         num_ports[0x8];
 
-	u8         reserved_at_1bf[0x3];
+	u8         reserved_at_1c0[0x3];
 	u8         log_max_msg[0x5];
-	u8         reserved_at_1c7[0x4];
+	u8         reserved_at_1c8[0x4];
 	u8         max_tc[0x4];
-	u8         reserved_at_1cf[0x6];
+	u8         reserved_at_1d0[0x6];
 	u8         rol_s[0x1];
 	u8         rol_g[0x1];
-	u8         reserved_at_1d7[0x1];
+	u8         reserved_at_1d8[0x1];
 	u8         wol_s[0x1];
 	u8         wol_g[0x1];
 	u8         wol_a[0x1];
@@ -774,47 +774,47 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         wol_p[0x1];
 
 	u8         stat_rate_support[0x10];
-	u8         reserved_at_1ef[0xc];
+	u8         reserved_at_1f0[0xc];
 	u8         cqe_version[0x4];
 
 	u8         compact_address_vector[0x1];
 	u8         reserved_at_200[0x3];
 	u8         ipoib_basic_offloads[0x1];
-	u8         reserved_at_204[0xa];
+	u8         reserved_at_205[0xa];
 	u8         drain_sigerr[0x1];
 	u8         cmdif_checksum[0x2];
 	u8         sigerr_cqe[0x1];
-	u8         reserved_at_212[0x1];
+	u8         reserved_at_213[0x1];
 	u8         wq_signature[0x1];
 	u8         sctr_data_cqe[0x1];
-	u8         reserved_at_215[0x1];
+	u8         reserved_at_216[0x1];
 	u8         sho[0x1];
 	u8         tph[0x1];
 	u8         rf[0x1];
 	u8         dct[0x1];
-	u8         reserved_at_21a[0x1];
+	u8         reserved_at_21b[0x1];
 	u8         eth_net_offloads[0x1];
 	u8         roce[0x1];
 	u8         atomic[0x1];
-	u8         reserved_at_21e[0x1];
+	u8         reserved_at_21f[0x1];
 
 	u8         cq_oi[0x1];
 	u8         cq_resize[0x1];
 	u8         cq_moderation[0x1];
-	u8         reserved_at_222[0x3];
+	u8         reserved_at_223[0x3];
 	u8         cq_eq_remap[0x1];
 	u8         pg[0x1];
 	u8         block_lb_mc[0x1];
-	u8         reserved_at_228[0x1];
+	u8         reserved_at_229[0x1];
 	u8         scqe_break_moderation[0x1];
 	u8         reserved_at_22a[0x1];
 	u8         cd[0x1];
-	u8         reserved_at_22c[0x1];
+	u8         reserved_at_22d[0x1];
 	u8         apm[0x1];
 	u8         vector_calc[0x1];
 	u8         reserved_at_22f[0x1];
 	u8	   imaicl[0x1];
-	u8         reserved_at_231[0x4];
+	u8         reserved_at_232[0x4];
 	u8         qkv[0x1];
 	u8         pkv[0x1];
 	u8         set_deth_sqpn[0x1];
@@ -824,98 +824,101 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         uc[0x1];
 	u8         rc[0x1];
 
-	u8         reserved_at_23f[0xa];
+	u8         reserved_at_240[0xa];
 	u8         uar_sz[0x6];
-	u8         reserved_at_24f[0x8];
+	u8         reserved_at_250[0x8];
 	u8         log_pg_sz[0x8];
 
 	u8         bf[0x1];
-	u8         reserved_at_260[0x1];
+	u8         reserved_at_261[0x1];
 	u8         pad_tx_eth_packet[0x1];
-	u8         reserved_at_262[0x8];
+	u8         reserved_at_263[0x8];
 	u8         log_bf_reg_size[0x5];
-	u8         reserved_at_26f[0x10];
+	u8         reserved_at_270[0x10];
 
-	u8         reserved_at_27f[0x10];
+	u8         reserved_at_280[0x10];
 	u8         max_wqe_sz_sq[0x10];
 
-	u8         reserved_at_29f[0x10];
+	u8         reserved_at_2a0[0x10];
 	u8         max_wqe_sz_rq[0x10];
 
-	u8         reserved_at_2bf[0x10];
+	u8         reserved_at_2c0[0x10];
 	u8         max_wqe_sz_sq_dc[0x10];
 
-	u8         reserved_at_2df[0x7];
+	u8         reserved_at_2e0[0x7];
 	u8         max_qp_mcg[0x19];
 
-	u8         reserved_at_2ff[0x18];
+	u8         reserved_at_300[0x18];
 	u8         log_max_mcg[0x8];
 
-	u8         reserved_at_31f[0x3];
+	u8         reserved_at_320[0x3];
 	u8         log_max_transport_domain[0x5];
-	u8         reserved_at_327[0x3];
+	u8         reserved_at_328[0x3];
 	u8         log_max_pd[0x5];
-	u8         reserved_at_32f[0xb];
+	u8         reserved_at_330[0xb];
 	u8         log_max_xrcd[0x5];
 
-	u8         reserved_at_33f[0x20];
+	u8         reserved_at_340[0x20];
 
-	u8         reserved_at_35f[0x3];
+	u8         reserved_at_360[0x3];
 	u8         log_max_rq[0x5];
-	u8         reserved_at_367[0x3];
+	u8         reserved_at_368[0x3];
 	u8         log_max_sq[0x5];
-	u8         reserved_at_36f[0x3];
+	u8         reserved_at_370[0x3];
 	u8         log_max_tir[0x5];
-	u8         reserved_at_377[0x3];
+	u8         reserved_at_378[0x3];
 	u8         log_max_tis[0x5];
 
 	u8         basic_cyclic_rcv_wqe[0x1];
-	u8         reserved_at_380[0x2];
+	u8         reserved_at_381[0x2];
 	u8         log_max_rmp[0x5];
-	u8         reserved_at_387[0x3];
+	u8         reserved_at_388[0x3];
 	u8         log_max_rqt[0x5];
-	u8         reserved_at_38f[0x3];
+	u8         reserved_at_390[0x3];
 	u8         log_max_rqt_size[0x5];
-	u8         reserved_at_397[0x3];
+	u8         reserved_at_398[0x3];
 	u8         log_max_tis_per_sq[0x5];
 
-	u8         reserved_at_39f[0x3];
+	u8         reserved_at_3a0[0x3];
 	u8         log_max_stride_sz_rq[0x5];
-	u8         reserved_at_3a7[0x3];
+	u8         reserved_at_3a8[0x3];
 	u8         log_min_stride_sz_rq[0x5];
-	u8         reserved_at_3af[0x3];
+	u8         reserved_at_3b0[0x3];
 	u8         log_max_stride_sz_sq[0x5];
-	u8         reserved_at_3b7[0x3];
+	u8         reserved_at_3b8[0x3];
 	u8         log_min_stride_sz_sq[0x5];
 
-	u8         reserved_at_3bf[0x1b];
+	u8         reserved_at_3c0[0x1b];
 	u8         log_max_wq_sz[0x5];
 
 	u8         nic_vport_change_event[0x1];
-	u8         reserved_at_3e0[0xa];
+	u8         reserved_at_3e1[0xa];
 	u8         log_max_vlan_list[0x5];
-	u8         reserved_at_3ef[0x3];
+	u8         reserved_at_3f0[0x3];
 	u8         log_max_current_mc_list[0x5];
-	u8         reserved_at_3f7[0x3];
+	u8         reserved_at_3f8[0x3];
 	u8         log_max_current_uc_list[0x5];
 
-	u8         reserved_at_3ff[0x80];
+	u8         reserved_at_400[0x80];
 
-	u8         reserved_at_47f[0x3];
+	u8         reserved_at_480[0x3];
 	u8         log_max_l2_table[0x5];
-	u8         reserved_at_487[0x8];
+	u8         reserved_at_488[0x8];
 	u8         log_uar_page_sz[0x10];
 
-	u8         reserved_at_49f[0x20];
+	u8         reserved_at_4a0[0x20];
 	u8         device_frequency_mhz[0x20];
 	u8         device_frequency_khz[0x20];
-	u8         reserved_at_4ff[0x5f];
+
+	u8         reserved_at_500[0x80];
+
+	u8         reserved_at_580[0x3f];
 	u8         cqe_zip[0x1];
 
 	u8         cqe_zip_timeout[0x10];
 	u8         cqe_zip_max_num[0x10];
 
-	u8         reserved_at_57f[0x220];
+	u8         reserved_at_5e0[0x220];
 };
 
 enum mlx5_flow_destination_type {
-- 
1.7.1

[PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Saeed Mahameed]

Adding the needed mlx5_ifc hardware bits and structs
for the following feature:

* Add vport to steering commands for SRIOV ACL support
* Add mlcr, pcmr and mcia registers for dump module EEPROM
* Add support for FCS, baeacon led and disable_link bits to
  hca caps
* Add CQE period mode bit in  CQ context for CQE based CQ
  moderation support
* Add umr SQ bit for fragmented memory registration
* Add needed bits and caps for Striding RQ support

Signed-off-by: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 include/linux/mlx5/mlx5_ifc.h |  146 ++++++++++++++++++++++++++++++++++------
 1 files changed, 124 insertions(+), 22 deletions(-)

diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index c300e74..4ce4ea4 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -513,7 +513,9 @@ struct mlx5_ifc_per_protocol_networking_offload_caps_bits {
 	u8         max_lso_cap[0x5];
 	u8         reserved_at_10[0x4];
 	u8         rss_ind_tbl_cap[0x4];
-	u8         reserved_at_18[0x3];
+	u8         reg_umr_sq[0x1];
+	u8         scatter_fcs[0x1];
+	u8         reserved_at_1a[0x1];
 	u8         tunnel_lso_const_out_ip_id[0x1];
 	u8         reserved_at_1c[0x2];
 	u8         tunnel_statless_gre[0x1];
@@ -648,7 +650,7 @@ struct mlx5_ifc_vector_calc_cap_bits {
 enum {
 	MLX5_WQ_TYPE_LINKED_LIST  = 0x0,
 	MLX5_WQ_TYPE_CYCLIC       = 0x1,
-	MLX5_WQ_TYPE_STRQ         = 0x2,
+	MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ = 0x2,
 };
 
 enum {
@@ -753,7 +755,11 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8	   early_vf_enable[0x1];
 	u8         reserved_at_1a9[0x2];
 	u8         local_ca_ack_delay[0x5];
-	u8         reserved_at_1af[0x6];
+	u8         reserved_at_1af[0x2];
+	u8         ports_check[0x1];
+	u8         reserved_at_1b2[0x1];
+	u8         disable_link_up[0x1];
+	u8         beacon_led[0x1];
 	u8         port_type[0x2];
 	u8         num_ports[0x8];
 
@@ -778,7 +784,8 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         cqe_version[0x4];
 
 	u8         compact_address_vector[0x1];
-	u8         reserved_at_200[0x3];
+	u8         striding_rq[0x1];
+	u8         reserved_at_201[0x2];
 	u8         ipoib_basic_offloads[0x1];
 	u8         reserved_at_205[0xa];
 	u8         drain_sigerr[0x1];
@@ -807,12 +814,12 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         block_lb_mc[0x1];
 	u8         reserved_at_229[0x1];
 	u8         scqe_break_moderation[0x1];
-	u8         reserved_at_22a[0x1];
+	u8         cq_period_start_from_cqe[0x1];
 	u8         cd[0x1];
 	u8         reserved_at_22d[0x1];
 	u8         apm[0x1];
 	u8         vector_calc[0x1];
-	u8         reserved_at_22f[0x1];
+	u8         umr_ptr_rlky[0x1];
 	u8	   imaicl[0x1];
 	u8         reserved_at_232[0x4];
 	u8         qkv[0x1];
@@ -913,10 +920,10 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         reserved_at_500[0x80];
 
 	u8         reserved_at_580[0x3f];
-	u8         cqe_zip[0x1];
+	u8         cqe_compression[0x1];
 
-	u8         cqe_zip_timeout[0x10];
-	u8         cqe_zip_max_num[0x10];
+	u8         cqe_compression_timeout[0x10];
+	u8         cqe_compression_max_num[0x10];
 
 	u8         reserved_at_5e0[0x220];
 };
@@ -1000,7 +1007,13 @@ struct mlx5_ifc_wq_bits {
 	u8         reserved_at_118[0x3];
 	u8         log_wq_sz[0x5];
 
-	u8         reserved_at_120[0x4e0];
+	u8         reserved_at_120[0x15];
+	u8         log_wqe_num_of_strides[0x3];
+	u8         two_byte_shift_en[0x1];
+	u8         reserved_at_139[0x4];
+	u8         log_wqe_stride_size[0x3];
+
+	u8         reserved_at_140[0x4c0];
 
 	struct mlx5_ifc_cmd_pas_bits pas[0];
 };
@@ -2199,7 +2212,8 @@ struct mlx5_ifc_sqc_bits {
 	u8         flush_in_error_en[0x1];
 	u8         reserved_at_4[0x4];
 	u8         state[0x4];
-	u8         reserved_at_c[0x14];
+	u8         reg_umr[0x1];
+	u8         reserved_at_d[0x13];
 
 	u8         reserved_at_20[0x8];
 	u8         user_index[0x18];
@@ -2247,7 +2261,8 @@ enum {
 
 struct mlx5_ifc_rqc_bits {
 	u8         rlky[0x1];
-	u8         reserved_at_1[0x2];
+	u8         reserved_at_1[0x1];
+	u8         scatter_fcs[0x1];
 	u8         vsd[0x1];
 	u8         mem_rq_type[0x4];
 	u8         state[0x4];
@@ -2604,6 +2619,11 @@ enum {
 	MLX5_CQC_ST_FIRED                                 = 0xa,
 };
 
+enum {
+	MLX5_CQ_PERIOD_MODE_START_FROM_EQE = 0x0,
+	MLX5_CQ_PERIOD_MODE_START_FROM_CQE = 0x1,
+};
+
 struct mlx5_ifc_cqc_bits {
 	u8         status[0x4];
 	u8         reserved_at_4[0x4];
@@ -2612,8 +2632,8 @@ struct mlx5_ifc_cqc_bits {
 	u8         reserved_at_c[0x1];
 	u8         scqe_break_moderation_en[0x1];
 	u8         oi[0x1];
-	u8         reserved_at_f[0x2];
-	u8         cqe_zip_en[0x1];
+	u8         cq_period_mode[0x2];
+	u8         cqe_comp_en[0x1];
 	u8         mini_cqe_res_format[0x2];
 	u8         st[0x4];
 	u8         reserved_at_18[0x8];
@@ -2987,7 +3007,11 @@ struct mlx5_ifc_set_fte_in_bits {
 	u8         reserved_at_20[0x10];
 	u8         op_mod[0x10];
 
-	u8         reserved_at_40[0x40];
+	u8         other_vport[0x1];
+	u8         reserved_at_41[0xf];
+	u8         vport_number[0x10];
+
+	u8         reserved_at_60[0x20];
 
 	u8         table_type[0x8];
 	u8         reserved_at_88[0x18];
@@ -5181,7 +5205,11 @@ struct mlx5_ifc_destroy_flow_table_in_bits {
 	u8         reserved_at_20[0x10];
 	u8         op_mod[0x10];
 
-	u8         reserved_at_40[0x40];
+	u8         other_vport[0x1];
+	u8         reserved_at_41[0xf];
+	u8         vport_number[0x10];
+
+	u8         reserved_at_60[0x20];
 
 	u8         table_type[0x8];
 	u8         reserved_at_88[0x18];
@@ -5208,7 +5236,11 @@ struct mlx5_ifc_destroy_flow_group_in_bits {
 	u8         reserved_at_20[0x10];
 	u8         op_mod[0x10];
 
-	u8         reserved_at_40[0x40];
+	u8         other_vport[0x1];
+	u8         reserved_at_41[0xf];
+	u8         vport_number[0x10];
+
+	u8         reserved_at_60[0x20];
 
 	u8         table_type[0x8];
 	u8         reserved_at_88[0x18];
@@ -5349,7 +5381,11 @@ struct mlx5_ifc_delete_fte_in_bits {
 	u8         reserved_at_20[0x10];
 	u8         op_mod[0x10];
 
-	u8         reserved_at_40[0x40];
+	u8         other_vport[0x1];
+	u8         reserved_at_41[0xf];
+	u8         vport_number[0x10];
+
+	u8         reserved_at_60[0x20];
 
 	u8         table_type[0x8];
 	u8         reserved_at_88[0x18];
@@ -5795,7 +5831,11 @@ struct mlx5_ifc_create_flow_table_in_bits {
 	u8         reserved_at_20[0x10];
 	u8         op_mod[0x10];
 
-	u8         reserved_at_40[0x40];
+	u8         other_vport[0x1];
+	u8         reserved_at_41[0xf];
+	u8         vport_number[0x10];
+
+	u8         reserved_at_60[0x20];
 
 	u8         table_type[0x8];
 	u8         reserved_at_88[0x18];
@@ -5839,7 +5879,11 @@ struct mlx5_ifc_create_flow_group_in_bits {
 	u8         reserved_at_20[0x10];
 	u8         op_mod[0x10];
 
-	u8         reserved_at_40[0x40];
+	u8         other_vport[0x1];
+	u8         reserved_at_41[0xf];
+	u8         vport_number[0x10];
+
+	u8         reserved_at_60[0x20];
 
 	u8         table_type[0x8];
 	u8         reserved_at_88[0x18];
@@ -6372,6 +6416,17 @@ struct mlx5_ifc_ptys_reg_bits {
 	u8         reserved_at_1a0[0x60];
 };
 
+struct mlx5_ifc_mlcr_reg_bits {
+	u8         reserved_at_0[0x8];
+	u8         local_port[0x8];
+	u8         reserved_at_10[0x20];
+
+	u8         beacon_duration[0x10];
+	u8         reserved_at_40[0x10];
+
+	u8         beacon_remain[0x10];
+};
+
 struct mlx5_ifc_ptas_reg_bits {
 	u8         reserved_at_0[0x20];
 
@@ -6781,6 +6836,16 @@ struct mlx5_ifc_pamp_reg_bits {
 	u8         index_data[18][0x10];
 };
 
+struct mlx5_ifc_pcmr_reg_bits {
+	u8         reserved_at_0[0x8];
+	u8         local_port[0x8];
+	u8         reserved_at_10[0x2e];
+	u8         fcs_cap[0x1];
+	u8         reserved_at_3f[0x1f];
+	u8         fcs_chk[0x1];
+	u8         reserved_at_5f[0x1];
+};
+
 struct mlx5_ifc_lane_2_module_mapping_bits {
 	u8         reserved_at_0[0x6];
 	u8         rx_lane[0x2];
@@ -7117,6 +7182,7 @@ union mlx5_ifc_ports_control_registers_document_bits {
 	struct mlx5_ifc_pspa_reg_bits pspa_reg;
 	struct mlx5_ifc_ptas_reg_bits ptas_reg;
 	struct mlx5_ifc_ptys_reg_bits ptys_reg;
+	struct mlx5_ifc_mlcr_reg_bits mlcr_reg;
 	struct mlx5_ifc_pude_reg_bits pude_reg;
 	struct mlx5_ifc_pvlc_reg_bits pvlc_reg;
 	struct mlx5_ifc_slrg_reg_bits slrg_reg;
@@ -7150,7 +7216,11 @@ struct mlx5_ifc_set_flow_table_root_in_bits {
 	u8         reserved_at_20[0x10];
 	u8         op_mod[0x10];
 
-	u8         reserved_at_40[0x40];
+	u8         other_vport[0x1];
+	u8         reserved_at_41[0xf];
+	u8         vport_number[0x10];
+
+	u8         reserved_at_60[0x20];
 
 	u8         table_type[0x8];
 	u8         reserved_at_88[0x18];
@@ -7181,7 +7251,9 @@ struct mlx5_ifc_modify_flow_table_in_bits {
 	u8         reserved_at_20[0x10];
 	u8         op_mod[0x10];
 
-	u8         reserved_at_40[0x20];
+	u8         other_vport[0x1];
+	u8         reserved_at_41[0xf];
+	u8         vport_number[0x10];
 
 	u8         reserved_at_60[0x10];
 	u8         modify_field_select[0x10];
@@ -7247,4 +7319,34 @@ struct mlx5_ifc_qtct_reg_bits {
 	u8         tclass[0x3];
 };
 
+struct mlx5_ifc_mcia_reg_bits {
+	u8         l[0x1];
+	u8         reserved_at_1[0x7];
+	u8         module[0x8];
+	u8         reserved_at_10[0x8];
+	u8         status[0x8];
+
+	u8         i2c_device_address[0x8];
+	u8         page_number[0x8];
+	u8         device_address[0x10];
+
+	u8         reserved_at_40[0x10];
+	u8         size[0x10];
+
+	u8         reserved_at_60[0x20];
+
+	u8         dword_0[0x20];
+	u8         dword_1[0x20];
+	u8         dword_2[0x20];
+	u8         dword_3[0x20];
+	u8         dword_4[0x20];
+	u8         dword_5[0x20];
+	u8         dword_6[0x20];
+	u8         dword_7[0x20];
+	u8         dword_8[0x20];
+	u8         dword_9[0x20];
+	u8         dword_10[0x20];
+	u8         dword_11[0x20];
+};
+
 #endif /* MLX5_IFC_H */
-- 
1.7.1

--
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 for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Or Gerlitz]

On Mon, Apr 11, 2016 at 11:10 PM, Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
> Adding the needed mlx5_ifc hardware bits and structs
> for the following feature:

feature --> features

> * Add vport to steering commands for SRIOV ACL support
> * Add mlcr, pcmr and mcia registers for dump module EEPROM
> * Add support for FCS, baeacon led and disable_link bits to
>   hca caps
> * Add CQE period mode bit in  CQ context for CQE based CQ
>   moderation support
> * Add umr SQ bit for fragmented memory registration
> * Add needed bits and caps for Striding RQ support

AFAIK, all the above are features will go through net-next, what made
you anticipate conflicts with linux-rdma?
--
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 for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Saeed Mahameed]

On Tue, Apr 12, 2016 at 12:17 AM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> feature --> features

Correct, will fix.

>
>> * Add vport to steering commands for SRIOV ACL support
>> * Add mlcr, pcmr and mcia registers for dump module EEPROM
>> * Add support for FCS, baeacon led and disable_link bits to
>>   hca caps
>> * Add CQE period mode bit in  CQ context for CQE based CQ
>>   moderation support
>> * Add umr SQ bit for fragmented memory registration
>> * Add needed bits and caps for Striding RQ support
>
> AFAIK, all the above are features will go through net-next, what made
> you anticipate conflicts with linux-rdma?

FCS bit is needed also for rdma, so we took the liberty of updating
all the needed HW structs, bits, caps, etc ..
at once for all mlx5 features planned for 4.7 regardless of rdma/net conflicts.
--
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 for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Or Gerlitz]

On Tue, Apr 12, 2016 at 12:24 AM, Saeed Mahameed
<saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
> On Tue, Apr 12, 2016 at 12:17 AM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

>> feature --> features

> Correct, will fix.

>>> * Add vport to steering commands for SRIOV ACL support
>>> * Add mlcr, pcmr and mcia registers for dump module EEPROM
>>> * Add support for FCS, baeacon led and disable_link bits to hca caps
>>> * Add CQE period mode bit in  CQ context for CQE based CQ
>>>   moderation support
>>> * Add umr SQ bit for fragmented memory registration
>>> * Add needed bits and caps for Striding RQ support

>> AFAIK, all the above are features will go through net-next, what made
>> you anticipate conflicts with linux-rdma?

> FCS bit is needed also for rdma, so we took the liberty of updating
> all the needed HW structs, bits, caps, etc ..
> at once for all mlx5 features planned for 4.7 regardless of rdma/net conflicts.

The cover letter states that this series deals with shared code.

I guess you might also could extend it a bit to deal also with code
that you suspect could lead to conflicts, but I don't see why it
evolved to that extent.

Or.
--
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 for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Leon Romanovsky]

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

On Tue, Apr 12, 2016 at 12:37:34AM +0300, Or Gerlitz wrote:
> On Tue, Apr 12, 2016 at 12:24 AM, Saeed Mahameed
> <saeedm@dev.mellanox.co.il> wrote:
> > On Tue, Apr 12, 2016 at 12:17 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> 
> >> feature --> features
> 
> > Correct, will fix.
> 
> >>> * Add vport to steering commands for SRIOV ACL support
> >>> * Add mlcr, pcmr and mcia registers for dump module EEPROM
> >>> * Add support for FCS, baeacon led and disable_link bits to hca caps
> >>> * Add CQE period mode bit in  CQ context for CQE based CQ
> >>>   moderation support
> >>> * Add umr SQ bit for fragmented memory registration
> >>> * Add needed bits and caps for Striding RQ support
> 
> >> AFAIK, all the above are features will go through net-next, what made
> >> you anticipate conflicts with linux-rdma?
> 
> > FCS bit is needed also for rdma, so we took the liberty of updating
> > all the needed HW structs, bits, caps, etc ..
> > at once for all mlx5 features planned for 4.7 regardless of rdma/net conflicts.
> 
> The cover letter states that this series deals with shared code.
> 
> I guess you might also could extend it a bit to deal also with code
> that you suspect could lead to conflicts, but I don't see why it
> evolved to that extent.

Or,
All these micro-optimizations on this shared file can potentially lead
to undesired merge conflicts. Subsystem maintainers and Linus don't need to
deal with these conflicts at all.

It won't help to anyone to split this commit to more than one patch.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Or Gerlitz]

On Tue, Apr 12, 2016 at 8:15 AM, Leon Romanovsky <leon-2ukJVAZIZ/Y@public.gmane.org> wrote:
> On Tue, Apr 12, 2016 at 12:37:34AM +0300, Or Gerlitz wrote:
>> On Tue, Apr 12, 2016 at 12:24 AM, Saeed Mahameed
>> <saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
>> > On Tue, Apr 12, 2016 at 12:17 AM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> >> feature --> features
>>
>> > Correct, will fix.
>>
>> >>> * Add vport to steering commands for SRIOV ACL support
>> >>> * Add mlcr, pcmr and mcia registers for dump module EEPROM
>> >>> * Add support for FCS, baeacon led and disable_link bits to hca caps
>> >>> * Add CQE period mode bit in  CQ context for CQE based CQ
>> >>>   moderation support
>> >>> * Add umr SQ bit for fragmented memory registration
>> >>> * Add needed bits and caps for Striding RQ support
>>
>> >> AFAIK, all the above are features will go through net-next, what made
>> >> you anticipate conflicts with linux-rdma?
>>
>> > FCS bit is needed also for rdma, so we took the liberty of updating
>> > all the needed HW structs, bits, caps, etc ..
>> > at once for all mlx5 features planned for 4.7 regardless of rdma/net conflicts.
>>
>> The cover letter states that this series deals with shared code.
>>
>> I guess you might also could extend it a bit to deal also with code
>> that you suspect could lead to conflicts, but I don't see why it
>> evolved to that extent.
>
> Or,
> All these micro-optimizations on this shared file can potentially lead
> to undesired merge conflicts. Subsystem maintainers and Linus don't need to
> deal with these conflicts at all.

Leon,

Conflicts happens @ all times, life.

We (MLNX) didn't do a good job to minimize them as much as
possible on the 4.5 cycle (understatement) and did vast improvement
in the 4.6 cycle (one or two conflicts AFAIK and communicated  to Linus).

It's correct that Linus got really angry on these two conflicts but I have
communicated to him the fact that we did that improvement and we're talking
on two commits for a fairly large volume of patches, the response was, if you
do things right, we will happily keep working with you, people, go look.

I understand your desire to get it down to zero, but it's not gonna
work, pick another target.

For example, the networking community has a fairly large rc activity
(I would say 10-20x
vs rdma), so when Dave does his "merge-rebases" for net-next over net
and linus tree
(4-5 times in a release), he has to this way or another solve
conflicts, yes! ditto for
Linus during merge windows and to some extent in rc times too.

> It won't help to anyone to split this commit to more than one patch.

The commit change-log should make it clear what this is about, and it doesn't.
If you believe in something, state that clear, be precise.

As Saeed admitted the shared code in the commit spans maybe 2% of it.

The 1st commit deals with a field which is not used in the driver,
this is a cleanup
that you can do in rc (net) patch (remove the field all together) and
overall, w.o seeing
the down-stream patches that depend on the newly introduced fields,
how do you know there aren't such (unused) bits in the 2nd commit?

Or.
--
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 for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Leon Romanovsky]

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

On Tue, Apr 12, 2016 at 08:36:21AM +0300, Or Gerlitz wrote:
> Conflicts happens @ all times, life.
> 

...

> 
> I understand your desire to get it down to zero, but it's not gonna
> work, pick another target.

Maybe you are right and the time will show, but now we (Saeed, Matan and me)
are trying hard to achieve this goal.

> 
> For example, the networking community has a fairly large rc activity
> (I would say 10-20x
> vs rdma), so when Dave does his "merge-rebases" for net-next over net
> and linus tree
> (4-5 times in a release), he has to this way or another solve
> conflicts, yes! ditto for
> Linus during merge windows and to some extent in rc times too.

I don't see any harm in our desire to decrease work overhead from these
busy people.

> 
> > It won't help to anyone to split this commit to more than one patch.
> 
> The commit change-log should make it clear what this is about, and it doesn't.
> If you believe in something, state that clear, be precise.

I agree.

> 
> As Saeed admitted the shared code in the commit spans maybe 2% of it.
> 
> The 1st commit deals with a field which is not used in the driver,
> this is a cleanup
> that you can do in rc (net) patch (remove the field all together) and
> overall, w.o seeing

I don't agree with your point that cleanup should go to RC.

> the down-stream patches that depend on the newly introduced fields,
> how do you know there aren't such (unused) bits in the 2nd commit?

No, I don't know in advance, but the truth is that it doesn't bother
anyone, because we are exposing our internal HW to kernel clients and
doing it with minimal impact on the maintainers.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Saeed Mahameed]

On Tue, Apr 12, 2016 at 9:01 AM, Leon Romanovsky <leon@leon.nu> wrote:
> On Tue, Apr 12, 2016 at 08:36:21AM +0300, Or Gerlitz wrote:
>>
>> I understand your desire to get it down to zero, but it's not gonna
>> work, pick another target.
>
> Maybe you are right and the time will show, but now we (Saeed, Matan and me)
> are trying hard to achieve this goal.
>
>>
>> For example, the networking community has a fairly large rc activity
>> (I would say 10-20x
>> vs rdma), so when Dave does his "merge-rebases" for net-next over net
>> and linus tree
>> (4-5 times in a release), he has to this way or another solve
>> conflicts, yes! ditto for
>> Linus during merge windows and to some extent in rc times too.
>
> I don't see any harm in our desire to decrease work overhead from these
> busy people.
>
>>
>> > It won't help to anyone to split this commit to more than one patch.
>>
>> The commit change-log should make it clear what this is about, and it doesn't.
>> If you believe in something, state that clear, be precise.
>
> I agree.
>
>>
>> As Saeed admitted the shared code in the commit spans maybe 2% of it.
>>
>> The 1st commit deals with a field which is not used in the driver,
>> this is a cleanup
>> that you can do in rc (net) patch (remove the field all together) and
>> overall, w.o seeing

Or, I guess everybody here agrees that mlx5_ifc is our Connectx-4 pure
HW spec, written in C, isn't that cool ?
I see no harm updating our HW spec once in a kernel cycle revealing
new cool HW bits and interfaces
for anyone to use mlx5e/mlx5_core/mlx5_ib .. you name it.

Why would you break down this patch to many when no matter what you
do, at the end it would look the same ?
As Leon mentioned we MLNX maintainers prefer to update this file at
once when possible.

>
> I don't agree with your point that cleanup should go to RC.

I am with Leon on this one, the cleanup code is just cleanup for new
features to come,
it has nothing to do with RC (net).

>
>> the down-stream patches that depend on the newly introduced fields,
>> how do you know there aren't such (unused) bits in the 2nd commit?
>
> No, I don't know in advance, but the truth is that it doesn't bother
> anyone, because we are exposing our internal HW to kernel clients and
> doing it with minimal impact on the maintainers.

Yep, this is exactly what i am trying to say, there are no two ways to
describe/write (mlx5_ifc) code,
if it is a HW spec, why shouldn't it appear from day one ?

Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Or Gerlitz]

On Tue, Apr 12, 2016 at 9:01 AM, Leon Romanovsky <leon-2ukJVAZIZ/Y@public.gmane.org> wrote:
> On Tue, Apr 12, 2016 at 08:36:21AM +0300, Or Gerlitz wrote:

>> Conflicts happens @ all times, life.
>> I understand your desire to get it down to zero, but it's not gonna
>> work, pick another target.

> Maybe you are right and the time will show, but now we (Saeed, Matan and me)
> are trying hard to achieve this goal.

going with your approach, next you are going to define a goal of no RC time
conflicts between rdma and net, and this will slow down the already
terribly slow
(no 4.6 net mlx5 rc patches so far) process even further.

>> For example, the networking community has a fairly large rc activity
>> (I would say 10-20x
>> vs rdma), so when Dave does his "merge-rebases" for net-next over net
>> and linus tree
>> (4-5 times in a release), he has to this way or another solve
>> conflicts, yes! ditto for
>> Linus during merge windows and to some extent in rc times too.

> I don't see any harm in our desire to decrease work overhead from these
> busy people.

Desire is one thing, you took it too further to my taste.

>> > It won't help to anyone to split this commit to more than one patch.

>> The commit change-log should make it clear what this is about, and it doesn't.
>> If you believe in something, state that clear, be precise.

> I agree.

good, so please do that in the respin

>> As Saeed admitted the shared code in the commit spans maybe 2% of it.
>> The 1st commit deals with a field which is not used in the driver,
>> this is a cleanup
>> that you can do in rc (net) patch (remove the field all together) and
>> overall, w.o seeing

> I don't agree with your point that cleanup should go to RC.

>> the down-stream patches that depend on the newly introduced fields,
>> how do you know there aren't such (unused) bits in the 2nd commit?

> No, I don't know in advance, but the truth is that it doesn't bother
> anyone, because we are exposing our internal HW to kernel clients and
> doing it with minimal impact on the maintainers.

this is not the internal HW, it's the FW API and the FW API is stabilized
together with implementing the feature in the driver. We must not expose
unused fields since they might change/move or be eliminated as part of
the driver implementation and this creates extra noise and burden for other
developers and maintainers. The 1st patch should change to be elimination
of these two fields (cqe_zip_xxx and early VF enable) b/c they are not
used in the code.

Or.
--
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 for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Or Gerlitz]

On Tue, Apr 12, 2016 at 10:40 AM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:

> Why would you break down this patch to many when no matter what you
> do, at the end it would look the same ?
> As Leon mentioned we MLNX maintainers prefer to update this file at
> once when possible.

See my response to Leon. It happened to me many times in code review
that people gave
me patches that open X fields in the IFC file and their code used Y <<
X fields. I don't
want the IFC file to have even one unused field, and I think the
correct way to do that
is have both the IFC file and the driver changes in the same series. I
understand the trend
to have zero-conflicts, lets try that. Did you make sure all exposed
IFC fields are used?

Or.

Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

[Or Gerlitz]

We talked here, and the three MLNX mlx5 maintainers prefer things to
be such they submit a patch
to both trees (rdma and net-next) that contains the changes they plan
to the FW IFC file for that
-next release. They agreed that only fields that will be actually in
use by the driver will be exposed
in the IFC. So... let it be and good luck to us, maybe with even zero
-next conflicts on mlx5 between
to two subsystems, happy upstreaming.

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