netdev - Re: [PATCH net-next v2 09/10] bnxt: convert to new udp_tunnel

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]

Message-ID: <CACKFLimw9pGX5fvpM82z1ALtTvijH+DdWcEOaybhXPR6SPga7w@mail.gmail.com>
Date:   Thu, 9 Jul 2020 14:24:31 -0700
From:   Michael Chan <michael.chan@...adcom.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Edwin Peer <edwin.peer@...adcom.com>,
        emil.s.tantilov@...el.com, alexander.h.duyck@...ux.intel.com,
        jeffrey.t.kirsher@...el.com, Tariq Toukan <tariqt@...lanox.com>,
        mkubecek@...e.cz
Subject: Re: [PATCH net-next v2 09/10] bnxt: convert to new udp_tunnel_nic infra

On Thu, Jul 9, 2020 at 1:56 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Wed, 8 Jul 2020 22:27:13 -0700 Michael Chan wrote:
> > On Wed, Jul 8, 2020 at 6:18 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > > @@ -1752,10 +1752,8 @@ struct bnxt {
> > >  #define BNXT_FW_MAJ(bp)                ((bp)->fw_ver_code >> 48)
> > >
> > >         __be16                  vxlan_port;
> >
> > We can also do away with vxlan_port and nge_port, now that we no
> > longer need to pass the port from NDO to workqueue.  We just need to
> > initialize the 2 firmware tunnel IDs to INVALID_HW_RING_ID before use
> > and after free.  But it is ok the way you have it too.
>
> Seems like I need to send a v3 anyway - the only reason I kept them is
> to know if bnxt_hwrm_free_tunnel_ports() has to issue its commands or
> not.
>
> Are you suggesting I just add a flag that'd say "tunnel in use" instead
> of holding onto the ports?  Or free unconditionally?

Here's what I would do:

1. Change vxlan_fw_dst_port_id and nge_fw_dst_port_id to u16 and
initialize them to INVALID_HW_RING_ID.  This will indicate that the
ports are not offloaded.  The assignments of these fields to the fw
message will now need cpu_to_le16().

2. bnxt_hwrm_free_tunnel_ports() will check if
bp->vxlan_fw_dst_port_id == INVALID_HW_RING_ID before freeing.  After
freeing, it will set bp->vxlan_fw_dst_port_id to INVALID_HW_RING_ID.
Same for the Geneve port.