netdev - RE: [RFC PATCH mlx5-next 07/18] net/mlx5: Expose new packet reformat capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Jul 2018 21:57:34 +0000
From:   Mark Bloch <markb@...lanox.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
CC:     Doug Ledford <dledford@...hat.com>,
        Jason Gunthorpe <jgg@...lanox.com>,
        Leon Romanovsky <leonro@...lanox.com>,
        RDMA mailing list <linux-rdma@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        linux-netdev <netdev@...r.kernel.org>
Subject: RE: [RFC PATCH mlx5-next 07/18] net/mlx5: Expose new packet reformat
 capabilities


> -----Original Message-----
> From: Or Gerlitz [mailto:gerlitz.or@...il.com]
> Sent: Monday, July 16, 2018 2:33 PM
> To: Mark Bloch <markb@...lanox.com>
> Cc: Doug Ledford <dledford@...hat.com>; Jason Gunthorpe
> <jgg@...lanox.com>; Leon Romanovsky <leonro@...lanox.com>; RDMA
> mailing list <linux-rdma@...r.kernel.org>; Saeed Mahameed
> <saeedm@...lanox.com>; linux-netdev <netdev@...r.kernel.org>
> Subject: Re: [RFC PATCH mlx5-next 07/18] net/mlx5: Expose new packet
> reformat capabilities
> 
> On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky <leon@...nel.org>
> wrote:
> > From: Mark Bloch <markb@...lanox.com>
> >
> > Expose new abilities when creating a packet reformat context.
> >
> > The new types which can be created are:
> > MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL: Ability to create generic
> encap
> > opertion to be done by the HW.
> 
> opertion -> fix
> 
> > MLX5_REFORMAT_TYPE_L3_TUNNEL_TO_L2: Ability to create generic
> decap
> > opertion where the inner packet doesn't contain L2.
> 
> opertion -> fix
> 
> >
> > MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL: Ability to create generic
> encap
> > opertion to be done by the HW. The L2 of the original packet
> 
> opertion -> fix

Thx, will be fixed.

> 
> > is dropped.
> >
> > Signed-off-by: Mark Bloch <markb@...lanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@...lanox.com>
> > ---
> >  include/linux/mlx5/mlx5_ifc.h | 20 +++++++++++++++++---
> >  1 file changed, 17 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
> > index 059ec97e7b32..c71d711d4893 100644
> > --- a/include/linux/mlx5/mlx5_ifc.h
> > +++ b/include/linux/mlx5/mlx5_ifc.h
> > @@ -341,8 +341,13 @@ struct mlx5_ifc_flow_table_prop_layout_bits {
> >         u8         reserved_at_9[0x1];
> >         u8         pop_vlan[0x1];
> >         u8         push_vlan[0x1];
> > -       u8         reserved_at_c[0x14];
> > -
> > +       u8         reserved_at_c[0x3];
> > +       u8         reformat_and_vlan_action[0x1];
> 
> unused in downstream patches
> what is this BTW?

It's needed for competence for all the bits that deal with packet reformat.
The bit itself indicates whatever the flow table supports
reformat action with a vlan action (pop/push) in the same rule.
> 
> > +       u8         reserved_at_10[0x2];
> > +       u8         reformat_l3_tunnel_to_l2[0x1];
> > +       u8         reformat_l2_to_l3_tunnel[0x1];
> > +       u8         reformat_and_modify_action[0x1];
> 
> unused in downstream patches
> what is this BTW?

Bits to indicate whatever the flow table support the new packet reformat modes,
and setting reformat action with modify action in the same rule.
Those will be used once a FW which expose them is made available,  but as a feature/
cap flags I would like to expose them now.

Mark

> 
> 
> 
> > +       u8         reserved_at_15[0xb];
> >         u8         reserved_at_20[0x2];
> >         u8         log_max_ft_size[0x6];
> >         u8         log_max_modify_header_context[0x8];
> > @@ -551,7 +556,13 @@ struct mlx5_ifc_flow_table_nic_cap_bits {
> >         u8         nic_rx_multi_path_tirs[0x1];
> >         u8         nic_rx_multi_path_tirs_fts[0x1];
> >         u8         allow_sniffer_and_nic_rx_shared_tir[0x1];
> > -       u8         reserved_at_3[0x1fd];
> > +       u8         reserved_at_3[0x1d];
> > +       u8         encap_general_header[0x1];
> > +       u8         reserved_at_21[0xa];
> > +       u8         log_max_packet_reformat_context[0x5];
> > +       u8         reserved_at_30[0x6];
> > +       u8         max_encap_header_size[0xa];
> > +       u8         reserved_at_40[0x1c0];
> 
> we are inconsistent, for some fields the term "encap" remained wheres
> for other fields we moved to use "reformat" or "packet reformat" etc