[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190619074338.GG11611@mtr-leonro.mtl.com>
Date: Wed, 19 Jun 2019 07:43:41 +0000
From: Leon Romanovsky <leonro@...lanox.com>
To: Mark Bloch <markb@...lanox.com>
CC: Jianbo Liu <jianbol@...lanox.com>,
Saeed Mahameed <saeedm@...lanox.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
Roi Dayan <roid@...lanox.com>
Subject: Re: [PATCH mlx5-next 11/15] RDMA/mlx5: Add vport metadata matching
for IB representors
On Wed, Jun 19, 2019 at 07:26:54AM +0000, Mark Bloch wrote:
>
>
> On 6/18/2019 23:51, Leon Romanovsky wrote:
> > On Wed, Jun 19, 2019 at 06:40:16AM +0000, Jianbo Liu wrote:
> >> The 06/19/2019 13:04, Leon Romanovsky wrote:
> >>> On Wed, Jun 19, 2019 at 04:44:26AM +0000, Jianbo Liu wrote:
> >>>> The 06/18/2019 18:19, Leon Romanovsky wrote:
> >>>>> On Mon, Jun 17, 2019 at 07:23:30PM +0000, Saeed Mahameed wrote:
> >>>>>> From: Jianbo Liu <jianbol@...lanox.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@...lanox.com>
> >>>>>> Reviewed-by: Roi Dayan <roid@...lanox.com>
> >>>>>> Reviewed-by: Mark Bloch <markb@...lanox.com>
> >>>>>> Signed-off-by: Saeed Mahameed <saeedm@...lanox.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.
> >>>>
> >>>> No. They are in IB, and we don't want them be mixed up by the original
> >>>> functions in eswitch. Please ask Mark more about it.
> >>>
> >>> Please enlighten me.
> >>
> >> It was suggested by Mark in prevouis review.
> >> I think it's because there are in different modules, and better to with
> >> different names, so introduce there extra one line functions.
> >> Please correct me if I'm wrong, Mark...
> >
> > mlx5_ib is full of direct function calls to mlx5_core and it is done on
> > purpose for at least two reasons. First is to control in one place
> > all compilation options and expose proper API interface with and without
> > specific kernel config is on. Second is to emphasize that this is core
> > function and save us time in refactoring and reviewing.
>
> This was done in order to avoid #ifdef CONFIG_MLX5_ESWITCH,
> I want to hide (as much as possible) the interactions with the eswitch level in ib_rep.c/ib_rep.h
> so ib_rep.h will provide the stubs needed in case CONFIG_MLX5_ESWITCH isn't defined.
> (Today include/linux/mlx5/eswitch.h) doesn't provide any stubs, mlx5_eswitch_get_encap_mode()
> should have probably done the same.
This is exactly the problem, eswitch.h should provide stubs for all
exported functions, so other clients of eswitch won't need to deal with
various unrelated config options.
>
> As my long term goal is to break drivers/infiniband/hw/mlx5/main.c (that file is already 7000 LOC)
> I want to group together stuff in separate files.
Yes, it is right thing to do.
>
> If you prefer direct calls that's okay as well.
Yes, please.
>
> Mark
>
> >
> >>
> >>>
> >>>>
> >>>>> 2. It should be bool and not u32.
> >>>>>
> >>>>> Thanks
> >>>>
> >>>> --
> >>
> >> --
Powered by blists - more mailing lists