* Re: [PATCH mlx5-next 14/15] {IB, net}/mlx5: E-Switch, Use index of rep for vport to IB port mapping
From: Leon Romanovsky @ 2019-06-18 10:42 UTC (permalink / raw)
To: Saeed Mahameed
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Bodong Wang,
Parav Pandit, Mark Bloch
In-Reply-To: <20190617192247.25107-15-saeedm@mellanox.com>
On Mon, Jun 17, 2019 at 07:23:37PM +0000, Saeed Mahameed wrote:
> From: Bodong Wang <bodong@mellanox.com>
>
> In the single IB device mode, the mapping between vport number and
> rep relies on a counter. However for dynamic vport allocation, it is
> desired to keep consistent map of eswitch vport and IB port.
>
> Hence, simplify code to remove the free running counter and instead
> use the available vport index during load/unload sequence from the
> eswitch.
>
> Signed-off-by: Bodong Wang <bodong@mellanox.com>
> Suggested-by: Parav Pandit <parav@mellanox.com>
> Reviewed-by: Parav Pandit <parav@mellanox.com>
We are not adding multiple "*-by" for same user, please choose one.
Thanks
^ permalink raw reply
* Re: [PATCH mlx5-next 15/15] RDMA/mlx5: Cleanup rep when doing unload
From: Leon Romanovsky @ 2019-06-18 10:38 UTC (permalink / raw)
To: Saeed Mahameed
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Bodong Wang,
Mark Bloch, Parav Pandit
In-Reply-To: <20190617192247.25107-16-saeedm@mellanox.com>
On Mon, Jun 17, 2019 at 07:23:39PM +0000, Saeed Mahameed wrote:
> From: Bodong Wang <bodong@mellanox.com>
>
> When an IB rep is loaded, netdev for the same vport is saved for later
> reference. However, it's not cleaned up when doing unload. For ECPF,
> kernel crashes when driver is referring to the already removed netdev.
>
> Following steps lead to a shown call trace:
> 1. Create n VFs from host PF
> 2. Distroy the VFs
> 3. Run "rdma link" from ARM
>
> Call trace:
> mlx5_ib_get_netdev+0x9c/0xe8 [mlx5_ib]
> mlx5_query_port_roce+0x268/0x558 [mlx5_ib]
> mlx5_ib_rep_query_port+0x14/0x34 [mlx5_ib]
> ib_query_port+0x9c/0xfc [ib_core]
> fill_port_info+0x74/0x28c [ib_core]
> nldev_port_get_doit+0x1a8/0x1e8 [ib_core]
> rdma_nl_rcv_msg+0x16c/0x1c0 [ib_core]
> rdma_nl_rcv+0xe8/0x144 [ib_core]
> netlink_unicast+0x184/0x214
> netlink_sendmsg+0x288/0x354
> sock_sendmsg+0x18/0x2c
> __sys_sendto+0xbc/0x138
> __arm64_sys_sendto+0x28/0x34
> el0_svc_common+0xb0/0x100
> el0_svc_handler+0x6c/0x84
> el0_svc+0x8/0xc
>
> Cleanup the rep and netdev reference when unloading IB rep.
>
> Fixes: 26628e2d58c9 ("RDMA/mlx5: Move to single device multiport ports in switchdev mode")
> Signed-off-by: Bodong Wang <bodong@mellanox.com>
> Reviewed-by: Mark Bloch <markb@mellanox.com>
> Reviewed-by: Parav Pandit <parav@mellanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> drivers/infiniband/hw/mlx5/ib_rep.c | 18 +++++++++++-------
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
Thanks,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
^ permalink raw reply
* Re: [PATCH mlx5-next 12/15] net/mlx5: E-Switch, Enable vport metadata matching if firmware supports it
From: Leon Romanovsky @ 2019-06-18 10:35 UTC (permalink / raw)
To: Parav Pandit
Cc: Saeed Mahameed, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Jianbo Liu, Roi Dayan, Mark Bloch
In-Reply-To: <AM0PR05MB4866AA7738F3DE1D3CF47FFBD1EA0@AM0PR05MB4866.eurprd05.prod.outlook.com>
On Tue, Jun 18, 2019 at 10:24:49AM +0000, Parav Pandit wrote:
>
>
> > -----Original Message-----
> > From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> > owner@vger.kernel.org> On Behalf Of Saeed Mahameed
> > Sent: Tuesday, June 18, 2019 12:54 AM
> > To: Saeed Mahameed <saeedm@mellanox.com>; Leon Romanovsky
> > <leonro@mellanox.com>
> > Cc: netdev@vger.kernel.org; linux-rdma@vger.kernel.org; Jianbo Liu
> > <jianbol@mellanox.com>; Roi Dayan <roid@mellanox.com>; Mark Bloch
> > <markb@mellanox.com>
> > Subject: [PATCH mlx5-next 12/15] net/mlx5: E-Switch, Enable vport metadata
> > matching if firmware supports it
> >
> > From: Jianbo Liu <jianbol@mellanox.com>
> >
> > As the ingress ACL rules save vhca id and vport number to packet's metadata
> > REG_C_0, and the metadata matching for the rules in both fast path and slow
> > path are all added, enable this feature if supported.
> >
> > Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> > Reviewed-by: Roi Dayan <roid@mellanox.com>
> > Reviewed-by: Mark Bloch <markb@mellanox.com>
> > Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> > ---
> > .../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > index 363517e29d4c..5124219a31de 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > @@ -1906,12 +1906,25 @@ static int
> > esw_vport_ingress_common_config(struct mlx5_eswitch *esw,
> > return err;
> > }
> >
> > +static int esw_check_vport_match_metadata_supported(struct mlx5_eswitch
> > +*esw) {
> > + return (MLX5_CAP_ESW_FLOWTABLE(esw->dev,
> > fdb_to_vport_reg_c_id) &
> > + MLX5_FDB_TO_VPORT_REG_C_0) &&
> > + MLX5_CAP_ESW_FLOWTABLE(esw->dev, flow_source) &&
> > + MLX5_CAP_ESW(esw->dev, esw_uplink_ingress_acl) &&
> > + !mlx5_core_is_ecpf_esw_manager(esw->dev) &&
> > + !mlx5_ecpf_vport_exists(esw->dev);
> > +}
> > +
> struct mlx5_eswitch* should be const.
> return type should be bool.
It is also completely indigestible and should be break into peaces to
make it readable.
Thanks
^ permalink raw reply
* RE: [PATCH mlx5-next 05/15] net/mlx5: E-Switch, Tag packet with vport number in VF vports and uplink ingress ACLs
From: Parav Pandit @ 2019-06-18 10:31 UTC (permalink / raw)
To: Saeed Mahameed
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Jianbo Liu,
Eli Britstein, Roi Dayan, Mark Bloch
In-Reply-To: <20190617192247.25107-6-saeedm@mellanox.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Saeed Mahameed
> Sent: Tuesday, June 18, 2019 12:53 AM
> To: Saeed Mahameed <saeedm@mellanox.com>; Leon Romanovsky
> <leonro@mellanox.com>
> Cc: netdev@vger.kernel.org; linux-rdma@vger.kernel.org; Jianbo Liu
> <jianbol@mellanox.com>; Eli Britstein <elibr@mellanox.com>; Roi Dayan
> <roid@mellanox.com>; Mark Bloch <markb@mellanox.com>
> Subject: [PATCH mlx5-next 05/15] net/mlx5: E-Switch, Tag packet with vport
> number in VF vports and uplink ingress ACLs
>
> From: Jianbo Liu <jianbol@mellanox.com>
>
> When a dual-port VHCA sends a RoCE packet on its non-native port, and the
> packet arrives to its affiliated vport FDB, a mismatch might occur on the rules
> that match the packet source vport as it is not represented by single VHCA only
> in this case. So we change to match on metadata instead of source vport.
> To do that, a rule is created in all vports and uplink ingress ACLs, to save the
> source vport number and vhca id in the packet's metadata in order to match on
> it later.
> The metadata register used is the first of the 32-bit type C registers. It can be
> used for matching and header modify operations. The higher 16 bits of this
> register are for vhca id, and the lower 16 ones is for vport number.
> This change is not for dual-port RoCE only. If HW and FW allow, the vport
> metadata matching is enabled by default.
>
> Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> Reviewed-by: Eli Britstein <elibr@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
> Reviewed-by: Mark Bloch <markb@mellanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> .../net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +
> .../net/ethernet/mellanox/mlx5/core/eswitch.h | 9 +
> .../mellanox/mlx5/core/eswitch_offloads.c | 183 ++++++++++++++----
> include/linux/mlx5/eswitch.h | 3 +
> 4 files changed, 161 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> index a42a23e505df..1235fd84ae3a 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> @@ -1168,6 +1168,8 @@ void esw_vport_cleanup_ingress_rules(struct
> mlx5_eswitch *esw,
>
> vport->ingress.drop_rule = NULL;
> vport->ingress.allow_rule = NULL;
> +
> + esw_vport_del_ingress_acl_modify_metadata(esw, vport);
> }
>
> void esw_vport_disable_ingress_acl(struct mlx5_eswitch *esw, diff --git
> a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> index 8b9f2cf58e91..4417a195832e 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> @@ -68,6 +68,8 @@ struct vport_ingress {
> struct mlx5_flow_group *allow_spoofchk_only_grp;
> struct mlx5_flow_group *allow_untagged_only_grp;
> struct mlx5_flow_group *drop_grp;
> + int modify_metadata_id;
No need for random alignment. Just have one white space after int.
> + struct mlx5_flow_handle *modify_metadata_rule;
> struct mlx5_flow_handle *allow_rule;
> struct mlx5_flow_handle *drop_rule;
> struct mlx5_fc *drop_counter;
> @@ -196,6 +198,10 @@ struct mlx5_esw_functions {
> u16 num_vfs;
> };
>
> +enum {
> + MLX5_ESWITCH_VPORT_MATCH_METADATA = BIT(0), };
> +
> struct mlx5_eswitch {
> struct mlx5_core_dev *dev;
> struct mlx5_nb nb;
> @@ -203,6 +209,7 @@ struct mlx5_eswitch {
> struct hlist_head mc_table[MLX5_L2_ADDR_HASH_SIZE];
> struct workqueue_struct *work_queue;
> struct mlx5_vport *vports;
> + u32 flags;
Same as above, no need for extra aligment.
> int total_vports;
> int enabled_vports;
> /* Synchronize between vport change events @@ -240,6 +247,8 @@
> void esw_vport_disable_egress_acl(struct mlx5_eswitch *esw,
> struct mlx5_vport *vport);
> void esw_vport_disable_ingress_acl(struct mlx5_eswitch *esw,
> struct mlx5_vport *vport);
> +void esw_vport_del_ingress_acl_modify_metadata(struct mlx5_eswitch *esw,
> + struct mlx5_vport *vport);
>
> /* E-Switch API */
> int mlx5_eswitch_init(struct mlx5_core_dev *dev); diff --git
> a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> index 17abb98b48af..871ae44dc132 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> @@ -1555,32 +1555,16 @@ static void esw_offloads_devcom_cleanup(struct
> mlx5_eswitch *esw) static int esw_vport_ingress_prio_tag_config(struct
> mlx5_eswitch *esw,
> struct mlx5_vport *vport)
> {
> - struct mlx5_core_dev *dev = esw->dev;
> struct mlx5_flow_act flow_act = {0};
> struct mlx5_flow_spec *spec;
> int err = 0;
>
> /* For prio tag mode, there is only 1 FTEs:
> - * 1) Untagged packets - push prio tag VLAN, allow
> + * 1) Untagged packets - push prio tag VLAN and modify metadata if
> + * required, allow
> * Unmatched traffic is allowed by default
> */
>
> - if (!MLX5_CAP_ESW_INGRESS_ACL(dev, ft_support))
> - return -EOPNOTSUPP;
> -
> - esw_vport_cleanup_ingress_rules(esw, vport);
> -
> - err = esw_vport_enable_ingress_acl(esw, vport);
> - if (err) {
> - mlx5_core_warn(esw->dev,
> - "failed to enable prio tag ingress acl (%d) on
> vport[%d]\n",
> - err, vport->vport);
> - return err;
> - }
> -
> - esw_debug(esw->dev,
> - "vport[%d] configure ingress rules\n", vport->vport);
> -
> spec = kvzalloc(sizeof(*spec), GFP_KERNEL);
> if (!spec) {
> err = -ENOMEM;
> @@ -1596,6 +1580,12 @@ static int esw_vport_ingress_prio_tag_config(struct
> mlx5_eswitch *esw,
> flow_act.vlan[0].ethtype = ETH_P_8021Q;
> flow_act.vlan[0].vid = 0;
> flow_act.vlan[0].prio = 0;
> +
> + if (vport->ingress.modify_metadata_rule) {
> + flow_act.action |=
> MLX5_FLOW_CONTEXT_ACTION_MOD_HDR;
> + flow_act.modify_id = vport->ingress.modify_metadata_id;
> + }
> +
> vport->ingress.allow_rule =
> mlx5_add_flow_rules(vport->ingress.acl, spec,
> &flow_act, NULL, 0);
> @@ -1616,6 +1606,59 @@ static int esw_vport_ingress_prio_tag_config(struct
> mlx5_eswitch *esw,
> return err;
> }
>
> +static int esw_vport_add_ingress_acl_modify_metadata(struct mlx5_eswitch
> *esw,
> + struct mlx5_vport *vport)
> +{
> + u8 action[MLX5_UN_SZ_BYTES(set_action_in_add_action_in_auto)] =
> {};
> + struct mlx5_flow_act flow_act = {};
> + struct mlx5_flow_spec spec = {};
> + int err = 0;
> +
> + MLX5_SET(set_action_in, action, action_type,
> MLX5_ACTION_TYPE_SET);
> + MLX5_SET(set_action_in, action, field,
> MLX5_ACTION_IN_FIELD_METADATA_REG_C_0);
> + MLX5_SET(set_action_in, action, data,
> + mlx5_eswitch_get_vport_metadata_for_match(esw, vport-
> >vport));
> +
> + err = mlx5_modify_header_alloc(esw->dev,
> MLX5_FLOW_NAMESPACE_ESW_INGRESS,
> + 1, action, &vport-
> >ingress.modify_metadata_id);
> +
> + if (err) {
> + esw_warn(esw->dev,
> + "failed to alloc modify header for vport %d ingress acl
> (%d)\n",
> + vport->vport, err);
> + return err;
> + }
> +
> + flow_act.action = MLX5_FLOW_CONTEXT_ACTION_MOD_HDR |
> MLX5_FLOW_CONTEXT_ACTION_ALLOW;
> + flow_act.modify_id = vport->ingress.modify_metadata_id;
> + vport->ingress.modify_metadata_rule = mlx5_add_flow_rules(vport-
> >ingress.acl,
> + &spec,
> &flow_act, NULL, 0);
> + if (IS_ERR(vport->ingress.modify_metadata_rule)) {
> + err = PTR_ERR(vport->ingress.modify_metadata_rule);
> + esw_warn(esw->dev,
> + "failed to add setting metadata rule for vport %d
> ingress acl, err(%d)\n",
> + vport->vport, err);
> + vport->ingress.modify_metadata_rule = NULL;
> + goto out;
> + }
> +
> +out:
> + if (err)
> + mlx5_modify_header_dealloc(esw->dev, vport-
> >ingress.modify_metadata_id);
> + return err;
> +}
> +
> +void esw_vport_del_ingress_acl_modify_metadata(struct mlx5_eswitch *esw,
> + struct mlx5_vport *vport)
> +{
> + if (vport->ingress.modify_metadata_rule) {
> + mlx5_del_flow_rules(vport->ingress.modify_metadata_rule);
> + mlx5_modify_header_dealloc(esw->dev,
> +vport->ingress.modify_metadata_id);
> +
> + vport->ingress.modify_metadata_rule = NULL;
> + }
> +}
> +
> static int esw_vport_egress_prio_tag_config(struct mlx5_eswitch *esw,
> struct mlx5_vport *vport)
> {
> @@ -1623,6 +1666,9 @@ static int esw_vport_egress_prio_tag_config(struct
> mlx5_eswitch *esw,
> struct mlx5_flow_spec *spec;
> int err = 0;
>
> + if (!MLX5_CAP_GEN(esw->dev, prio_tag_required))
> + return 0;
> +
> /* For prio tag mode, there is only 1 FTEs:
> * 1) prio tag packets - pop the prio tag VLAN, allow
> * Unmatched traffic is allowed by default @@ -1676,27 +1722,77 @@
> static int esw_vport_egress_prio_tag_config(struct mlx5_eswitch *esw,
> return err;
> }
>
> -static int esw_prio_tag_acls_config(struct mlx5_eswitch *esw, int nvports)
> +static int esw_vport_ingress_common_config(struct mlx5_eswitch *esw,
> + struct mlx5_vport *vport)
> {
> - struct mlx5_vport *vport = NULL;
> - int i, j;
> int err;
>
> - mlx5_esw_for_each_vf_vport(esw, i, vport, nvports) {
> + if (!mlx5_eswitch_vport_match_metadata_enabled(esw) &&
> + !MLX5_CAP_GEN(esw->dev, prio_tag_required))
> + return 0;
> +
> + esw_vport_cleanup_ingress_rules(esw, vport);
> +
> + err = esw_vport_enable_ingress_acl(esw, vport);
> + if (err) {
> + esw_warn(esw->dev,
> + "failed to enable ingress acl (%d) on vport[%d]\n",
> + err, vport->vport);
> + return err;
> + }
> +
> + esw_debug(esw->dev,
> + "vport[%d] configure ingress rules\n", vport->vport);
> +
> + if (mlx5_eswitch_vport_match_metadata_enabled(esw)) {
> + err = esw_vport_add_ingress_acl_modify_metadata(esw,
> vport);
> + if (err)
> + goto out;
> + }
> +
> + if (MLX5_CAP_GEN(esw->dev, prio_tag_required) &&
> + (vport->vport >= MLX5_VPORT_FIRST_VF &&
> + vport->vport <= esw->dev->priv.sriov.num_vfs)) {
> err = esw_vport_ingress_prio_tag_config(esw, vport);
> if (err)
> - goto err_ingress;
> - err = esw_vport_egress_prio_tag_config(esw, vport);
> + goto out;
> + }
> +
> +out:
> + if (err)
> + esw_vport_disable_ingress_acl(esw, vport);
> + return err;
> +}
> +
> +static int esw_create_offloads_acl_tables(struct mlx5_eswitch *esw) {
> + struct mlx5_vport *vport;
> + int i, j;
> + int err;
> +
> + mlx5_esw_for_all_vports(esw, i, vport) {
> + err = esw_vport_ingress_common_config(esw, vport);
> if (err)
> - goto err_egress;
> + goto err_ingress;
> +
> + if (vport->vport >= MLX5_VPORT_FIRST_VF &&
> + vport->vport <= esw->dev->priv.sriov.num_vfs) {
Add an helper API mlx5_esw_is_vport(const struct mlx5_esw *esw, const struct mlx5_vport *vport)
and use at two places in ingress and egress config.
> + err = esw_vport_egress_prio_tag_config(esw, vport);
> + if (err)
> + goto err_egress;
> + }
> }
>
> + if (mlx5_eswitch_vport_match_metadata_enabled(esw))
> + esw_info(esw->dev, "Use metadata reg_c as source vport to
> match\n");
> +
> return 0;
>
> err_egress:
> esw_vport_disable_ingress_acl(esw, vport);
> err_ingress:
> - mlx5_esw_for_each_vf_vport_reverse(esw, j, vport, i - 1) {
> + for (j = MLX5_VPORT_PF; j < i; j++) {
Keep the reverse order as before.
> + vport = &esw->vports[j];
> esw_vport_disable_egress_acl(esw, vport);
> esw_vport_disable_ingress_acl(esw, vport);
> }
> @@ -1704,15 +1800,17 @@ static int esw_prio_tag_acls_config(struct
> mlx5_eswitch *esw, int nvports)
> return err;
> }
>
> -static void esw_prio_tag_acls_cleanup(struct mlx5_eswitch *esw)
> +static void esw_destroy_offloads_acl_tables(struct mlx5_eswitch *esw)
> {
> struct mlx5_vport *vport;
> int i;
>
> - mlx5_esw_for_each_vf_vport(esw, i, vport, esw->nvports) {
> + mlx5_esw_for_all_vports(esw, i, vport) {
If you are changing this, please do in reverse order to keep it exact mirror of create/enable sequence.
> esw_vport_disable_egress_acl(esw, vport);
> esw_vport_disable_ingress_acl(esw, vport);
> }
> +
> + esw->flags &= ~MLX5_ESWITCH_VPORT_MATCH_METADATA;
> }
>
> static int esw_offloads_steering_init(struct mlx5_eswitch *esw, int nvports)
> @@ -1722,15 +1820,13 @@ static int esw_offloads_steering_init(struct
> mlx5_eswitch *esw, int nvports)
> memset(&esw->fdb_table.offloads, 0, sizeof(struct offloads_fdb));
> mutex_init(&esw->fdb_table.offloads.fdb_prio_lock);
>
> - if (MLX5_CAP_GEN(esw->dev, prio_tag_required)) {
> - err = esw_prio_tag_acls_config(esw, nvports);
> - if (err)
> - return err;
> - }
> + err = esw_create_offloads_acl_tables(esw);
> + if (err)
> + return err;
>
> err = esw_create_offloads_fdb_tables(esw, nvports);
> if (err)
> - return err;
> + goto create_fdb_err;
>
> err = esw_create_offloads_table(esw, nvports);
> if (err)
> @@ -1748,6 +1844,9 @@ static int esw_offloads_steering_init(struct
> mlx5_eswitch *esw, int nvports)
> create_ft_err:
> esw_destroy_offloads_fdb_tables(esw);
>
> +create_fdb_err:
> + esw_destroy_offloads_acl_tables(esw);
> +
> return err;
> }
>
> @@ -1756,8 +1855,7 @@ static void esw_offloads_steering_cleanup(struct
> mlx5_eswitch *esw)
> esw_destroy_vport_rx_group(esw);
> esw_destroy_offloads_table(esw);
> esw_destroy_offloads_fdb_tables(esw);
> - if (MLX5_CAP_GEN(esw->dev, prio_tag_required))
> - esw_prio_tag_acls_cleanup(esw);
> + esw_destroy_offloads_acl_tables(esw);
> }
>
> static void esw_functions_changed_event_handler(struct work_struct *work)
> @@ -2290,3 +2388,16 @@ struct mlx5_eswitch_rep
> *mlx5_eswitch_vport_rep(struct mlx5_eswitch *esw,
> return mlx5_eswitch_get_rep(esw, vport); }
> EXPORT_SYMBOL(mlx5_eswitch_vport_rep);
> +
> +u32 mlx5_eswitch_vport_match_metadata_enabled(struct mlx5_eswitch
> *esw)
> +{
> + return esw->flags & MLX5_ESWITCH_VPORT_MATCH_METADATA;
> +}
> +EXPORT_SYMBOL(mlx5_eswitch_vport_match_metadata_enabled);
> +
Return type should book and const *esw.
> +u32 mlx5_eswitch_get_vport_metadata_for_match(struct mlx5_eswitch *esw,
> + u16 vport)
> +{
> + return ((MLX5_CAP_GEN(esw->dev, vhca_id) & 0xffff) << 16) | vport; }
> +EXPORT_SYMBOL(mlx5_eswitch_get_vport_metadata_for_match);
This one too.
> diff --git a/include/linux/mlx5/eswitch.h b/include/linux/mlx5/eswitch.h index
> 174eec0871d9..d729f5e4d70a 100644
> --- a/include/linux/mlx5/eswitch.h
> +++ b/include/linux/mlx5/eswitch.h
> @@ -64,6 +64,9 @@ struct mlx5_flow_handle *
> mlx5_eswitch_add_send_to_vport_rule(struct mlx5_eswitch *esw,
> int vport, u32 sqn);
>
> +u32 mlx5_eswitch_vport_match_metadata_enabled(struct mlx5_eswitch
> +*esw);
> +u32 mlx5_eswitch_get_vport_metadata_for_match(struct mlx5_eswitch *esw,
> +u16 vport);
> +
> #ifdef CONFIG_MLX5_ESWITCH
> enum devlink_eswitch_encap_mode
> mlx5_eswitch_get_encap_mode(const struct mlx5_core_dev *dev);
> --
> 2.21.0
^ permalink raw reply
* RE: [PATCH mlx5-next 12/15] net/mlx5: E-Switch, Enable vport metadata matching if firmware supports it
From: Parav Pandit @ 2019-06-18 10:24 UTC (permalink / raw)
To: Saeed Mahameed
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Jianbo Liu,
Roi Dayan, Mark Bloch
In-Reply-To: <20190617192247.25107-13-saeedm@mellanox.com>
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Saeed Mahameed
> Sent: Tuesday, June 18, 2019 12:54 AM
> To: Saeed Mahameed <saeedm@mellanox.com>; Leon Romanovsky
> <leonro@mellanox.com>
> Cc: netdev@vger.kernel.org; linux-rdma@vger.kernel.org; Jianbo Liu
> <jianbol@mellanox.com>; Roi Dayan <roid@mellanox.com>; Mark Bloch
> <markb@mellanox.com>
> Subject: [PATCH mlx5-next 12/15] net/mlx5: E-Switch, Enable vport metadata
> matching if firmware supports it
>
> From: Jianbo Liu <jianbol@mellanox.com>
>
> As the ingress ACL rules save vhca id and vport number to packet's metadata
> REG_C_0, and the metadata matching for the rules in both fast path and slow
> path are all added, enable this feature if supported.
>
> Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
> Reviewed-by: Mark Bloch <markb@mellanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> .../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> index 363517e29d4c..5124219a31de 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> @@ -1906,12 +1906,25 @@ static int
> esw_vport_ingress_common_config(struct mlx5_eswitch *esw,
> return err;
> }
>
> +static int esw_check_vport_match_metadata_supported(struct mlx5_eswitch
> +*esw) {
> + return (MLX5_CAP_ESW_FLOWTABLE(esw->dev,
> fdb_to_vport_reg_c_id) &
> + MLX5_FDB_TO_VPORT_REG_C_0) &&
> + MLX5_CAP_ESW_FLOWTABLE(esw->dev, flow_source) &&
> + MLX5_CAP_ESW(esw->dev, esw_uplink_ingress_acl) &&
> + !mlx5_core_is_ecpf_esw_manager(esw->dev) &&
> + !mlx5_ecpf_vport_exists(esw->dev);
> +}
> +
struct mlx5_eswitch* should be const.
return type should be bool.
^ permalink raw reply
* Re: [PATCH mlx5-next 11/15] RDMA/mlx5: Add vport metadata matching for IB representors
From: Leon Romanovsky @ 2019-06-18 10:19 UTC (permalink / raw)
To: Saeed Mahameed
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Jianbo Liu,
Roi Dayan, Mark Bloch
In-Reply-To: <20190617192247.25107-12-saeedm@mellanox.com>
On Mon, Jun 17, 2019 at 07:23:30PM +0000, Saeed Mahameed wrote:
> From: Jianbo Liu <jianbol@mellanox.com>
>
> If vport metadata matching is enabled in eswitch, the rule created
> must be changed to match on the metadata, instead of source port.
>
> Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
> Reviewed-by: Mark Bloch <markb@mellanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> drivers/infiniband/hw/mlx5/ib_rep.c | 11 +++++++
> drivers/infiniband/hw/mlx5/ib_rep.h | 16 ++++++++++
> drivers/infiniband/hw/mlx5/main.c | 45 +++++++++++++++++++++++------
> 3 files changed, 63 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/ib_rep.c b/drivers/infiniband/hw/mlx5/ib_rep.c
> index 22e651cb5534..d4ed611de35d 100644
> --- a/drivers/infiniband/hw/mlx5/ib_rep.c
> +++ b/drivers/infiniband/hw/mlx5/ib_rep.c
> @@ -131,6 +131,17 @@ struct mlx5_eswitch_rep *mlx5_ib_vport_rep(struct mlx5_eswitch *esw, int vport)
> return mlx5_eswitch_vport_rep(esw, vport);
> }
>
> +u32 mlx5_ib_eswitch_vport_match_metadata_enabled(struct mlx5_eswitch *esw)
> +{
> + return mlx5_eswitch_vport_match_metadata_enabled(esw);
> +}
> +
> +u32 mlx5_ib_eswitch_get_vport_metadata_for_match(struct mlx5_eswitch *esw,
> + u16 vport)
> +{
> + return mlx5_eswitch_get_vport_metadata_for_match(esw, vport);
> +}
1. There is no need to introduce one line functions, call to that code directly.
2. It should be bool and not u32.
Thanks
^ permalink raw reply
* Re: [PATCH v17 03/15] arm64: Introduce prctl() options to control the tagged user addresses ABI
From: Dave Martin @ 2019-06-18 9:18 UTC (permalink / raw)
To: Kees Cook
Cc: Catalin Marinas, Mark Rutland, kvm, Christian Koenig,
Szabolcs Nagy, Will Deacon, dri-devel, Kostya Serebryany,
Khalid Aziz, Lee Smith, linux-kselftest, Vincenzo Frascino,
Jacob Bramley, Leon Romanovsky, linux-rdma, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Evgeniy Stepanov, linux-media, Ruben
In-Reply-To: <201906132209.FC65A3C771@keescook>
On Thu, Jun 13, 2019 at 10:13:54PM -0700, Kees Cook wrote:
> On Thu, Jun 13, 2019 at 04:26:32PM +0100, Catalin Marinas wrote:
> > On Thu, Jun 13, 2019 at 12:02:35PM +0100, Dave P Martin wrote:
> > > On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
> > > > +static int zero;
> > > > +static int one = 1;
> > >
> > > !!!
> > >
> > > And these can't even be const without a cast. Yuk.
> > >
> > > (Not your fault though, but it would be nice to have a proc_dobool() to
> > > avoid this.)
> >
> > I had the same reaction. Maybe for another patch sanitising this pattern
> > across the kernel.
>
> That's actually already happening (via -mm tree last I looked). tl;dr:
> it ends up using a cast hidden in a macro. It's in linux-next already
> along with a checkpatch.pl addition to yell about doing what's being
> done here. ;)
>
> https://lore.kernel.org/lkml/20190430180111.10688-1-mcroce@redhat.com/#r
Hmmm, that is marginally less bad.
Ideally we'd have a union in there, not just a bunch of void *. I may
look at that someday...
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH v3 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release
From: Christoph Hellwig @ 2019-06-18 5:37 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrea Arcangeli, Philip Yang, Ralph Campbell,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, John Hubbard,
Felix.Kuehling-5C7GfCeVMHo,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Christoph Hellwig,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, Jerome Glisse,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Ben Skeggs
In-Reply-To: <20190618004509.GE30762-uk2M96/98Pc@public.gmane.org>
On Mon, Jun 17, 2019 at 09:45:09PM -0300, Jason Gunthorpe wrote:
> Am I looking at the wrong thing? Looks like it calls it through a work
> queue should should be OK..
Yes, it calls it through a work queue. I guess that is fine because
it needs to take the lock again.
> Though very strange that amdgpu only destroys the mirror via release,
> that cannot be right.
As said the whole things looks rather odd to me.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH 7/8] mpt3sas: set an unlimited max_segment_size for SAS 3.0 HBAs
From: Ming Lei @ 2019-06-18 0:46 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Martin K . Petersen, Sagi Grimberg, Max Gurtovoy, Bart Van Assche,
linux-rdma, Linux SCSI List, megaraidlinux.pdl,
MPT-FusionLinux.pdl, linux-hyperv, Linux Kernel Mailing List
In-Reply-To: <20190617122000.22181-8-hch@lst.de>
On Mon, Jun 17, 2019 at 8:21 PM Christoph Hellwig <hch@lst.de> wrote:
>
> When using a virt_boundary_mask, as done for NVMe devices attached to
> mpt3sas controllers we require an unlimited max_segment_size, as the
> virt boundary merging code assumes that. But we also need to propagate
> that to the DMA mapping layer to make dma-debug happy. The SCSI layer
> takes care of that when using the per-host virt_boundary setting, but
> given that mpt3sas only wants to set the virt_boundary for actual
> NVMe devices we can't rely on that. The DMA layer maximum segment
> is global to the HBA however, so we have to set it explicitly. This
> patch assumes that mpt3sas does not have a segment size limitation,
> which seems true based on the SGL format, but will need to be verified.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 1ccfbc7eebe0..c719b807f6d8 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -10222,6 +10222,7 @@ static struct scsi_host_template mpt3sas_driver_template = {
> .this_id = -1,
> .sg_tablesize = MPT3SAS_SG_DEPTH,
> .max_sectors = 32767,
> + .max_segment_size = 0xffffffff,
.max_segment_size should be aligned, either setting it here correctly or
forcing to make it aligned in scsi-core.
Thanks,
Ming Lei
^ permalink raw reply
* Re: [PATCH v3 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release
From: Jason Gunthorpe @ 2019-06-18 0:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrea Arcangeli, Philip Yang, Ralph Campbell, linux-rdma,
John Hubbard, Felix.Kuehling, dri-devel, linux-mm, Jerome Glisse,
amd-gfx, Ben Skeggs
In-Reply-To: <20190615142106.GK17724@infradead.org>
On Sat, Jun 15, 2019 at 07:21:06AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:49PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe <jgg@mellanox.com>
> >
> > hmm_release() is called exactly once per hmm. ops->release() cannot
> > accidentally trigger any action that would recurse back onto
> > hmm->mirrors_sem.
>
> In linux-next amdgpu actually calls hmm_mirror_unregister from its
> release function. That whole release function looks rather sketchy,
> but we probably need to sort that out first.
Does it? I see this:
static void amdgpu_hmm_mirror_release(struct hmm_mirror *mirror)
{
struct amdgpu_mn *amn = container_of(mirror, struct amdgpu_mn, mirror);
INIT_WORK(&amn->work, amdgpu_mn_destroy);
schedule_work(&amn->work);
}
static struct hmm_mirror_ops amdgpu_hmm_mirror_ops[] = {
[AMDGPU_MN_TYPE_GFX] = {
.sync_cpu_device_pagetables = amdgpu_mn_sync_pagetables_gfx,
.release = amdgpu_hmm_mirror_release
},
[AMDGPU_MN_TYPE_HSA] = {
.sync_cpu_device_pagetables = amdgpu_mn_sync_pagetables_hsa,
.release = amdgpu_hmm_mirror_release
},
};
Am I looking at the wrong thing? Looks like it calls it through a work
queue should should be OK..
Though very strange that amdgpu only destroys the mirror via release,
that cannot be right.
Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 hmm 10/12] mm/hmm: Do not use list*_rcu() for hmm->ranges
From: Jason Gunthorpe @ 2019-06-18 0:38 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrea Arcangeli, Philip Yang, Ralph Campbell, linux-rdma,
John Hubbard, Felix.Kuehling, Ira Weiny, dri-devel,
Souptick Joarder, linux-mm, Jerome Glisse, amd-gfx, Ben Skeggs
In-Reply-To: <20190615141826.GJ17724@infradead.org>
On Sat, Jun 15, 2019 at 07:18:26AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:48PM -0300, Jason Gunthorpe wrote:
> > range->hmm = hmm;
> > kref_get(&hmm->kref);
> > - list_add_rcu(&range->list, &hmm->ranges);
> > + list_add(&range->list, &hmm->ranges);
> >
> > /*
> > * If there are any concurrent notifiers we have to wait for them for
> > @@ -934,7 +934,7 @@ void hmm_range_unregister(struct hmm_range *range)
> > struct hmm *hmm = range->hmm;
> >
> > mutex_lock(&hmm->lock);
> > - list_del_rcu(&range->list);
> > + list_del(&range->list);
> > mutex_unlock(&hmm->lock);
>
> Looks fine:
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Btw, is there any reason new ranges are added to the front and not the
> tail of the list?
Couldn't find one. I think order on this list doesn't matter.
Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 hmm 04/12] mm/hmm: Simplify hmm_get_or_create and make it reliable
From: Jason Gunthorpe @ 2019-06-18 0:36 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrea Arcangeli, Philip Yang, Ralph Campbell, linux-rdma,
John Hubbard, Felix.Kuehling, dri-devel, linux-mm, Jerome Glisse,
amd-gfx, Ira Weiny, Ben Skeggs
In-Reply-To: <20190615141211.GD17724@infradead.org>
On Sat, Jun 15, 2019 at 07:12:11AM -0700, Christoph Hellwig wrote:
> > + spin_lock(&mm->page_table_lock);
> > + if (mm->hmm) {
> > + if (kref_get_unless_zero(&mm->hmm->kref)) {
> > + spin_unlock(&mm->page_table_lock);
> > + return mm->hmm;
> > + }
> > + }
> > + spin_unlock(&mm->page_table_lock);
>
> This could become:
>
> spin_lock(&mm->page_table_lock);
> hmm = mm->hmm
> if (hmm && kref_get_unless_zero(&hmm->kref))
> goto out_unlock;
> spin_unlock(&mm->page_table_lock);
>
> as the last two lines of the function already drop the page_table_lock
> and then return hmm. Or drop the "hmm = mm->hmm" asignment above and
> return mm->hmm as that should be always identical to hmm at the end
> to save another line.
Yeah, I can fuss it some more.
> > + /*
> > + * The mm->hmm pointer is kept valid while notifier ops can be running
> > + * so they don't have to deal with a NULL mm->hmm value
> > + */
>
> The comment confuses me. How does the page_table_lock relate to
> possibly running notifiers, as I can't find that we take
> page_table_lock? Or is it just about the fact that we only clear
> mm->hmm in the free callback, and not in hmm_free?
It was late when I wrote this fixup, the comment is faulty, and there
is no reason to delay this until the SRCU cleanup at this point in the
series.
The ops all get their struct hmm from container_of, the only thing
that refers to mm->hmm is hmm_get_or_create().
I'll revise it tomorrow, the comment will go away and the =NULL will
go to the release callback
Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/8] scsi: add a host / host template field for the virt boundary
From: Ming Lei @ 2019-06-18 0:35 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Martin K . Petersen, Sagi Grimberg, Max Gurtovoy, Bart Van Assche,
linux-rdma, Linux SCSI List, megaraidlinux.pdl,
MPT-FusionLinux.pdl, linux-hyperv, Linux Kernel Mailing List
In-Reply-To: <20190617122000.22181-2-hch@lst.de>
On Mon, Jun 17, 2019 at 8:21 PM Christoph Hellwig <hch@lst.de> wrote:
>
> This allows drivers setting it up easily instead of branching out to
> block layer calls in slave_alloc, and ensures the upgraded
> max_segment_size setting gets picked up by the DMA layer.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/scsi/hosts.c | 3 +++
> drivers/scsi/scsi_lib.c | 3 ++-
> include/scsi/scsi_host.h | 3 +++
> 3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index ff0d8c6a8d0c..55522b7162d3 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -462,6 +462,9 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
> else
> shost->dma_boundary = 0xffffffff;
>
> + if (sht->virt_boundary_mask)
> + shost->virt_boundary_mask = sht->virt_boundary_mask;
> +
> device_initialize(&shost->shost_gendev);
> dev_set_name(&shost->shost_gendev, "host%d", shost->host_no);
> shost->shost_gendev.bus = &scsi_bus_type;
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 65d0a10c76ad..d333bb6b1c59 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1775,7 +1775,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
> dma_set_seg_boundary(dev, shost->dma_boundary);
>
> blk_queue_max_segment_size(q, shost->max_segment_size);
> - dma_set_max_seg_size(dev, shost->max_segment_size);
> + blk_queue_virt_boundary(q, shost->virt_boundary_mask);
> + dma_set_max_seg_size(dev, queue_max_segment_size(q));
The patch looks fine, also suggest to make sure that max_segment_size
is block-size aligned, and un-aligned max segment size has caused trouble
on mmc.
Thanks,
Ming Lei
^ permalink raw reply
* Re: [PATCH v17 03/15] arm64: Introduce prctl() options to control the tagged user addresses ABI
From: Evgenii Stepanov @ 2019-06-17 21:59 UTC (permalink / raw)
To: Catalin Marinas
Cc: Andrey Konovalov, Linux ARM, Linux Memory Management List, LKML,
amd-gfx, dri-devel, linux-rdma, linux-media, kvm,
open list:KERNEL SELFTEST FRAMEWORK, Vincenzo Frascino,
Will Deacon, Mark Rutland, Andrew Morton, Greg Kroah-Hartman,
Kees Cook, Yishai Hadas, Felix Kuehling, Alexander Deucher
In-Reply-To: <20190617171813.GC34565@arrakis.emea.arm.com>
On Mon, Jun 17, 2019 at 10:18 AM Catalin Marinas
<catalin.marinas@arm.com> wrote:
>
> On Mon, Jun 17, 2019 at 09:57:36AM -0700, Evgenii Stepanov wrote:
> > On Mon, Jun 17, 2019 at 6:56 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
> > > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > >
> > > > It is not desirable to relax the ABI to allow tagged user addresses into
> > > > the kernel indiscriminately. This patch introduces a prctl() interface
> > > > for enabling or disabling the tagged ABI with a global sysctl control
> > > > for preventing applications from enabling the relaxed ABI (meant for
> > > > testing user-space prctl() return error checking without reconfiguring
> > > > the kernel). The ABI properties are inherited by threads of the same
> > > > application and fork()'ed children but cleared on execve().
> > > >
> > > > The PR_SET_TAGGED_ADDR_CTRL will be expanded in the future to handle
> > > > MTE-specific settings like imprecise vs precise exceptions.
> > > >
> > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > >
> > > A question for the user-space folk: if an application opts in to this
> > > ABI, would you want the sigcontext.fault_address and/or siginfo.si_addr
> > > to contain the tag? We currently clear it early in the arm64 entry.S but
> > > we could find a way to pass it down if needed.
> >
> > For HWASan this would not be useful because we instrument memory
> > accesses with explicit checks anyway. For MTE, on the other hand, it
> > would be very convenient to know the fault address tag without
> > disassembling the code.
>
> I could as this differently: does anything break if, once the user
> opts in to TBI, fault_address and/or si_addr have non-zero top byte?
I think it would be fine.
> Alternatively, we could present the original FAR_EL1 register as a
> separate field as we do with ESR_EL1, independently of whether the user
> opted in to TBI or not.
>
> --
> Catalin
^ permalink raw reply
* Re: [PATCH] net/mlx5e: reduce stack usage in mlx5_eswitch_termtbl_create
From: Saeed Mahameed @ 2019-06-17 21:30 UTC (permalink / raw)
To: davem@davemloft.net, arnd@arndb.de
Cc: linux-rdma@vger.kernel.org, Or Gerlitz, Oz Shlomo, Paul Blakey,
Mark Bloch, Maor Gottlieb, linux-kernel@vger.kernel.org,
Eli Britstein, netdev@vger.kernel.org, leon@kernel.org
In-Reply-To: <20190617.140230.537297372523260104.davem@davemloft.net>
On Mon, 2019-06-17 at 14:02 -0700, David Miller wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Mon, 17 Jun 2019 13:08:22 +0200
>
> > Putting an empty 'mlx5_flow_spec' structure on the stack is a bit
> > wasteful and causes a warning on 32-bit architectures when building
> > with clang -fsanitize-coverage:
> >
> > drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c:
> > In function 'mlx5_eswitch_termtbl_create':
> > drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c:
> > 90:1: error: the frame size of 1032 bytes is larger than 1024 bytes
> > [-Werror=frame-larger-than=]
> >
> > Since the structure is never written to, we can statically allocate
> > it to avoid the stack usage. To be on the safe side, mark all
> > subsequent function arguments that we pass it into as 'const'
> > as well.
> >
> > Fixes: 10caabdaad5a ("net/mlx5e: Use termination table for VLAN
> > push actions")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Saeed, once Arnd fixes the reverse christmas tree issue, I assume you
> will take
> this in via your tree?
Yes, this is a core change that might conflict with some ongoing stuff.
Thank you Dave !
Saeed.
^ permalink raw reply
* Re: [PATCH] net/mlx5e: reduce stack usage in mlx5_eswitch_termtbl_create
From: David Miller @ 2019-06-17 21:02 UTC (permalink / raw)
To: arnd
Cc: saeedm, leon, ozsh, paulb, elibr, markb, ogerlitz, maorg, netdev,
linux-rdma, linux-kernel
In-Reply-To: <20190617110855.2085326-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 17 Jun 2019 13:08:22 +0200
> Putting an empty 'mlx5_flow_spec' structure on the stack is a bit
> wasteful and causes a warning on 32-bit architectures when building
> with clang -fsanitize-coverage:
>
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c: In function 'mlx5_eswitch_termtbl_create':
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c:90:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> Since the structure is never written to, we can statically allocate
> it to avoid the stack usage. To be on the safe side, mark all
> subsequent function arguments that we pass it into as 'const'
> as well.
>
> Fixes: 10caabdaad5a ("net/mlx5e: Use termination table for VLAN push actions")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Saeed, once Arnd fixes the reverse christmas tree issue, I assume you will take
this in via your tree?
Thanks.
^ permalink raw reply
* Re: [PATCH 6/8] IB/srp: set virt_boundary_mask in the scsi host
From: Bart Van Assche @ 2019-06-17 21:01 UTC (permalink / raw)
To: Christoph Hellwig, Martin K . Petersen
Cc: Sagi Grimberg, Max Gurtovoy, linux-rdma, linux-scsi,
megaraidlinux.pdl, MPT-FusionLinux.pdl, linux-hyperv,
linux-kernel
In-Reply-To: <20190617122000.22181-7-hch@lst.de>
On 6/17/19 5:19 AM, Christoph Hellwig wrote:
> This ensures all proper DMA layer handling is taken care of by the
> SCSI midlayer.
Acked-by: Bart Van Assche <bvanassche@acm.org>
^ permalink raw reply
* Re: [PATCH 4/8] storvsc: set virt_boundary_mask in the scsi host template
From: Bart Van Assche @ 2019-06-17 20:59 UTC (permalink / raw)
To: Christoph Hellwig, Martin K . Petersen
Cc: Sagi Grimberg, Max Gurtovoy, linux-rdma, linux-scsi,
megaraidlinux.pdl, MPT-FusionLinux.pdl, linux-hyperv,
linux-kernel
In-Reply-To: <20190617122000.22181-5-hch@lst.de>
On 6/17/19 5:19 AM, Christoph Hellwig wrote:
> This ensures all proper DMA layer handling is taken care of by the
> SCSI midlayer.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/scsi/storvsc_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index b89269120a2d..7ed6f2fc1446 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1422,9 +1422,6 @@ static int storvsc_device_configure(struct scsi_device *sdevice)
> {
> blk_queue_rq_timeout(sdevice->request_queue, (storvsc_timeout * HZ));
>
> - /* Ensure there are no gaps in presented sgls */
> - blk_queue_virt_boundary(sdevice->request_queue, PAGE_SIZE - 1);
> -
> sdevice->no_write_same = 1;
>
> /*
> @@ -1697,6 +1694,8 @@ static struct scsi_host_template scsi_driver = {
> .this_id = -1,
> /* Make sure we dont get a sg segment crosses a page boundary */
> .dma_boundary = PAGE_SIZE-1,
> + /* Ensure there are no gaps in presented sgls */
> + .virt_boundary_mask = PAGE_SIZE-1,
> .no_write_same = 1,
> .track_queue_depth = 1,
> };
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
^ permalink raw reply
* Re: [PATCH 3/8] ufshcd: set max_segment_size in the scsi host template
From: Bart Van Assche @ 2019-06-17 20:58 UTC (permalink / raw)
To: Christoph Hellwig, Martin K . Petersen
Cc: Sagi Grimberg, Max Gurtovoy, linux-rdma, linux-scsi,
megaraidlinux.pdl, MPT-FusionLinux.pdl, linux-hyperv,
linux-kernel
In-Reply-To: <20190617122000.22181-4-hch@lst.de>
On 6/17/19 5:19 AM, Christoph Hellwig wrote:
> We need to also mirror the value to the device to ensure IOMMU merging
> doesn't undo it, and the SCSI host level parameter will ensure that.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/scsi/ufs/ufshcd.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 3fe3029617a8..505d625ed28d 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -4587,8 +4587,6 @@ static int ufshcd_slave_configure(struct scsi_device *sdev)
> struct request_queue *q = sdev->request_queue;
>
> blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
> - blk_queue_max_segment_size(q, PRDT_DATA_BYTE_COUNT_MAX);
> -
> return 0;
> }
>
> @@ -6991,6 +6989,7 @@ static struct scsi_host_template ufshcd_driver_template = {
> .sg_tablesize = SG_ALL,
> .cmd_per_lun = UFSHCD_CMD_PER_LUN,
> .can_queue = UFSHCD_CAN_QUEUE,
> + .max_segment_size = PRDT_DATA_BYTE_COUNT_MAX,
> .max_host_blocked = 1,
> .track_queue_depth = 1,
> .sdev_groups = ufshcd_driver_groups,
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
^ permalink raw reply
* Re: [PATCH 2/8] scsi: take the DMA max mapping size into account
From: Bart Van Assche @ 2019-06-17 20:56 UTC (permalink / raw)
To: Christoph Hellwig, Martin K . Petersen
Cc: Sagi Grimberg, Max Gurtovoy, linux-rdma, linux-scsi,
megaraidlinux.pdl, MPT-FusionLinux.pdl, linux-hyperv,
linux-kernel
In-Reply-To: <20190617122000.22181-3-hch@lst.de>
On 6/17/19 5:19 AM, Christoph Hellwig wrote:
> We need to limit the devices max_sectors to what the DMA mapping
> implementation can support. If not we risk running out of swiotlb
> buffers easily.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/scsi/scsi_lib.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index d333bb6b1c59..f233bfd84cd7 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1768,6 +1768,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
> blk_queue_max_integrity_segments(q, shost->sg_prot_tablesize);
> }
>
> + shost->max_sectors = min_t(unsigned int, shost->max_sectors,
> + dma_max_mapping_size(dev) << SECTOR_SHIFT);
> blk_queue_max_hw_sectors(q, shost->max_sectors);
> if (shost->unchecked_isa_dma)
> blk_queue_bounce_limit(q, BLK_BOUNCE_ISA);
Does dma_max_mapping_size() return a value in bytes? Is
shost->max_sectors a number of sectors? If so, are you sure that "<<
SECTOR_SHIFT" is the proper conversion? Shouldn't that be ">>
SECTOR_SHIFT" instead?
Additionally, how about adding a comment above dma_max_mapping_size()
that documents the unit of the returned number?
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 1/8] scsi: add a host / host template field for the virt boundary
From: Bart Van Assche @ 2019-06-17 20:51 UTC (permalink / raw)
To: Christoph Hellwig, Martin K . Petersen
Cc: Sagi Grimberg, Max Gurtovoy, linux-rdma, linux-scsi,
megaraidlinux.pdl, MPT-FusionLinux.pdl, linux-hyperv,
linux-kernel
In-Reply-To: <20190617122000.22181-2-hch@lst.de>
On 6/17/19 5:19 AM, Christoph Hellwig wrote:
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 65d0a10c76ad..d333bb6b1c59 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1775,7 +1775,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
> dma_set_seg_boundary(dev, shost->dma_boundary);
>
> blk_queue_max_segment_size(q, shost->max_segment_size);
> - dma_set_max_seg_size(dev, shost->max_segment_size);
> + blk_queue_virt_boundary(q, shost->virt_boundary_mask);
> + dma_set_max_seg_size(dev, queue_max_segment_size(q));
Although this looks fine to me for LLDs that own a PCIe device, I doubt
this is correct for SCSI LLDs that share a PCIe device with other ULP
drivers. From the RDMA core:
/* Setup default max segment size for all IB devices */
dma_set_max_seg_size(device->dma_device, SZ_2G);
Will instantiating a SCSI host (iSER or SRP) for an RDMA adapter cause
the maximum segment size to be modified for all ULP drivers associated
with that HCA?
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH rdma-next v1 0/4] Expose ENCAP mode to mlx5_ib
From: Doug Ledford @ 2019-06-17 20:18 UTC (permalink / raw)
To: Leon Romanovsky, Jason Gunthorpe
Cc: RDMA mailing list, Maor Gottlieb, Mark Bloch, Parav Pandit,
Petr Vorel, Saeed Mahameed, linux-netdev, Jiri Pirko
In-Reply-To: <20190616124357.GH4694@mtr-leonro.mtl.com>
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
On Sun, 2019-06-16 at 12:44 +0000, Leon Romanovsky wrote:
> On Wed, Jun 12, 2019 at 03:20:10PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Changelog v0->v1:
> > * Added patch to devlink to use declared enum for encap mode
> > instead of u8
> > * Constify input argumetn to encap mode function
> > * fix encap variable type to be boolean
> >
> > -----------------------------------------------------------------
> > ----
> > Hi,
> >
> > This is short series from Maor to expose and use enacap mode inside
> > mlx5_ib.
> >
> > Thanks
> >
> > Leon Romanovsky (1):
> > net/mlx5: Declare more strictly devlink encap mode
> >
> > Maor Gottlieb (3):
> > net/mlx5: Expose eswitch encap mode
>
> Those two applied to mlx5-next
> 82b11f071936 net/mlx5: Expose eswitch encap mode
> 98fdbea55037 net/mlx5: Declare more strictly devlink encap mode
>
> > RDMA/mlx5: Consider eswitch encap mode
> > RDMA/mlx5: Enable decap and packet reformat on FDB
>
> Doug, Jason
>
> Can you please take those two patches in addition to latest mlx5-
> next?
Done, thanks.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57
2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] RDMA/odp: Fix missed unlock in non-blocking invalidate_start
From: Doug Ledford @ 2019-06-17 19:56 UTC (permalink / raw)
To: Leon Romanovsky, Jason Gunthorpe
Cc: linux-rdma, Moni Shoua, Jason Gunthorpe, stable
In-Reply-To: <20190612161536.GS6369@mtr-leonro.mtl.com>
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
On Wed, 2019-06-12 at 19:15 +0300, Leon Romanovsky wrote:
> On Tue, Jun 11, 2019 at 01:09:51PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe <jgg@mellanox.com>
> >
> > If invalidate_start returns with EAGAIN then the umem_rwsem needs
> > to be
> > unlocked as no invalidate_end will be called.
> >
> > Cc: <stable@vger.kernel.org>
> > Fixes: ca748c39ea3f ("RDMA/umem: Get rid of per_mm-
> > >notifier_count")
> > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
> > ---
> > drivers/infiniband/core/umem_odp.c | 14 +++++++++-----
> > 1 file changed, 9 insertions(+), 5 deletions(-)
> >
>
> Thanks,
> Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Thanks, applied to for-next.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57
2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH mlx5-next 15/15] RDMA/mlx5: Cleanup rep when doing unload
From: Saeed Mahameed @ 2019-06-17 19:23 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Bodong Wang,
Mark Bloch, Parav Pandit
In-Reply-To: <20190617192247.25107-1-saeedm@mellanox.com>
From: Bodong Wang <bodong@mellanox.com>
When an IB rep is loaded, netdev for the same vport is saved for later
reference. However, it's not cleaned up when doing unload. For ECPF,
kernel crashes when driver is referring to the already removed netdev.
Following steps lead to a shown call trace:
1. Create n VFs from host PF
2. Distroy the VFs
3. Run "rdma link" from ARM
Call trace:
mlx5_ib_get_netdev+0x9c/0xe8 [mlx5_ib]
mlx5_query_port_roce+0x268/0x558 [mlx5_ib]
mlx5_ib_rep_query_port+0x14/0x34 [mlx5_ib]
ib_query_port+0x9c/0xfc [ib_core]
fill_port_info+0x74/0x28c [ib_core]
nldev_port_get_doit+0x1a8/0x1e8 [ib_core]
rdma_nl_rcv_msg+0x16c/0x1c0 [ib_core]
rdma_nl_rcv+0xe8/0x144 [ib_core]
netlink_unicast+0x184/0x214
netlink_sendmsg+0x288/0x354
sock_sendmsg+0x18/0x2c
__sys_sendto+0xbc/0x138
__arm64_sys_sendto+0x28/0x34
el0_svc_common+0xb0/0x100
el0_svc_handler+0x6c/0x84
el0_svc+0x8/0xc
Cleanup the rep and netdev reference when unloading IB rep.
Fixes: 26628e2d58c9 ("RDMA/mlx5: Move to single device multiport ports in switchdev mode")
Signed-off-by: Bodong Wang <bodong@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
Reviewed-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/infiniband/hw/mlx5/ib_rep.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/ib_rep.c b/drivers/infiniband/hw/mlx5/ib_rep.c
index da4b936b3219..a4a54ddebb71 100644
--- a/drivers/infiniband/hw/mlx5/ib_rep.c
+++ b/drivers/infiniband/hw/mlx5/ib_rep.c
@@ -17,6 +17,7 @@ mlx5_ib_set_vport_rep(struct mlx5_core_dev *dev, struct mlx5_eswitch_rep *rep)
vport_index = rep->vport_index;
ibdev->port[vport_index].rep = rep;
+ rep->rep_data[REP_IB].priv = ibdev;
write_lock(&ibdev->port[vport_index].roce.netdev_lock);
ibdev->port[vport_index].roce.netdev =
mlx5_ib_get_rep_netdev(dev->priv.eswitch, rep->vport);
@@ -68,15 +69,18 @@ mlx5_ib_vport_rep_load(struct mlx5_core_dev *dev, struct mlx5_eswitch_rep *rep)
static void
mlx5_ib_vport_rep_unload(struct mlx5_eswitch_rep *rep)
{
- struct mlx5_ib_dev *dev;
-
- if (!rep->rep_data[REP_IB].priv ||
- rep->vport != MLX5_VPORT_UPLINK)
- return;
+ struct mlx5_ib_dev *dev = mlx5_ib_rep_to_dev(rep);
+ struct mlx5_ib_port *port;
- dev = mlx5_ib_rep_to_dev(rep);
- __mlx5_ib_remove(dev, dev->profile, MLX5_IB_STAGE_MAX);
+ port = &dev->port[rep->vport_index];
+ write_lock(&port->roce.netdev_lock);
+ port->roce.netdev = NULL;
+ write_unlock(&port->roce.netdev_lock);
rep->rep_data[REP_IB].priv = NULL;
+ port->rep = NULL;
+
+ if (rep->vport == MLX5_VPORT_UPLINK)
+ __mlx5_ib_remove(dev, dev->profile, MLX5_IB_STAGE_MAX);
}
static void *mlx5_ib_vport_get_proto_dev(struct mlx5_eswitch_rep *rep)
--
2.21.0
^ permalink raw reply related
* [PATCH mlx5-next 14/15] {IB, net}/mlx5: E-Switch, Use index of rep for vport to IB port mapping
From: Saeed Mahameed @ 2019-06-17 19:23 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Bodong Wang,
Parav Pandit, Mark Bloch
In-Reply-To: <20190617192247.25107-1-saeedm@mellanox.com>
From: Bodong Wang <bodong@mellanox.com>
In the single IB device mode, the mapping between vport number and
rep relies on a counter. However for dynamic vport allocation, it is
desired to keep consistent map of eswitch vport and IB port.
Hence, simplify code to remove the free running counter and instead
use the available vport index during load/unload sequence from the
eswitch.
Signed-off-by: Bodong Wang <bodong@mellanox.com>
Suggested-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/infiniband/hw/mlx5/ib_rep.c | 4 ++--
drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 -
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 1 +
include/linux/mlx5/eswitch.h | 2 ++
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/ib_rep.c b/drivers/infiniband/hw/mlx5/ib_rep.c
index d4ed611de35d..da4b936b3219 100644
--- a/drivers/infiniband/hw/mlx5/ib_rep.c
+++ b/drivers/infiniband/hw/mlx5/ib_rep.c
@@ -14,7 +14,7 @@ mlx5_ib_set_vport_rep(struct mlx5_core_dev *dev, struct mlx5_eswitch_rep *rep)
int vport_index;
ibdev = mlx5_ib_get_uplink_ibdev(dev->priv.eswitch);
- vport_index = ibdev->free_port++;
+ vport_index = rep->vport_index;
ibdev->port[vport_index].rep = rep;
write_lock(&ibdev->port[vport_index].roce.netdev_lock);
@@ -50,7 +50,7 @@ mlx5_ib_vport_rep_load(struct mlx5_core_dev *dev, struct mlx5_eswitch_rep *rep)
}
ibdev->is_rep = true;
- vport_index = ibdev->free_port++;
+ vport_index = rep->vport_index;
ibdev->port[vport_index].rep = rep;
ibdev->port[vport_index].roce.netdev =
mlx5_ib_get_rep_netdev(dev->priv.eswitch, rep->vport);
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index 1c205c2bd486..ee73dc122d28 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -978,7 +978,6 @@ struct mlx5_ib_dev {
u16 devx_whitelist_uid;
struct mlx5_srq_table srq_table;
struct mlx5_async_ctx async_ctx;
- int free_port;
};
static inline struct mlx5_ib_cq *to_mibcq(struct mlx5_core_cq *mcq)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index f29b9e1f49ae..7fdea5600383 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -1411,6 +1411,7 @@ int esw_offloads_init_reps(struct mlx5_eswitch *esw)
mlx5_esw_for_all_reps(esw, vport_index, rep) {
rep->vport = mlx5_eswitch_index_to_vport_num(esw, vport_index);
+ rep->vport_index = vport_index;
ether_addr_copy(rep->hw_id, hw_id);
for (rep_type = 0; rep_type < NUM_REP_TYPES; rep_type++)
diff --git a/include/linux/mlx5/eswitch.h b/include/linux/mlx5/eswitch.h
index d729f5e4d70a..d29abefa03c6 100644
--- a/include/linux/mlx5/eswitch.h
+++ b/include/linux/mlx5/eswitch.h
@@ -46,6 +46,8 @@ struct mlx5_eswitch_rep {
u16 vport;
u8 hw_id[ETH_ALEN];
u16 vlan;
+ /* Only IB rep is using vport_index */
+ u16 vport_index;
u32 vlan_refcount;
};
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox