netdev - [PATCH net-next 0/9] nfp: flower: decap neighbour table rework

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-next>] [day] [month] [year] [list]

Date:   Thu,  5 May 2022 14:43:39 +0900
From:   Simon Horman <simon.horman@...igine.com>
To:     David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, oss-drivers@...igine.com
Subject: [PATCH net-next 0/9] nfp: flower: decap neighbour table rework

Louis Peens says:

This patch series reworks the way in which flow rules that outputs to
OVS internal ports gets handled by the nfp driver.

Previously this made use of a small pre_tun_table, but this only used
destination MAC addresses, and made the implicit assumption that there is
only a single source MAC":"destination MAC" mapping per tunnel. In
hindsight this seems to be a pretty obvious oversight, but this was hidden
in plain sight for quite some time.

This series changes the implementation to make use of the same Neighbour
table for decap that is in use for the tunnel encap solution. It stores
any new Neighbour updates in this table. Previously this path was only
triggered for encapsulation candidates, and the entries were send and
forget, not saved on the host as it is after this series. It also keeps
track of any flow rule that outputs to OVS internal ports (and some
other criteria not worth mentioning here), very similar to how it was
done previously, except now these flows are kept track of in a list.

When a new Neighbour entry gets added this list gets iterated for
potential matches, in which case the table gets updated with a reference
to the flow, and the Neighbour entry on the card gets updated with the
relevant host_ctx. The same happens when a new qualifying flow gets
added - the Neighbour table gets iterated for applicable matches, and
once again the firmware gets updated with the host_ctx when any matches
are found.

Since this also requires a firmware change we add a new capability bit,
and keep the old behaviour in case of older firmware without this bit
set.

This series starts by doing some preparation, then adding the new list
and table entries. Next the functionality to link/unlink these entries
are added, and finally this new functionality is enabled by adding the
DECAP_V2 bit to the driver feature list.

Louis Peens (9):
  nfp: flower: add infrastructure for pre_tun rework
  nfp: flower: add/remove predt_list entries
  nfp: flower: enforce more strict pre_tun checks
  nfp: flower: fixup ipv6/ipv4 route lookup for neigh events
  nfp: flower: update nfp_tun_neigh structs
  nfp: flower: rework tunnel neighbour configuration
  nfp: flower: link pre_tun flow rules with neigh entries
  nfp: flower: remove unused neighbour cache
  nfp: flower: enable decap_v2 bit

 .../ethernet/netronome/nfp/flower/action.c    |   3 +-
 .../net/ethernet/netronome/nfp/flower/main.h  | 110 +++-
 .../ethernet/netronome/nfp/flower/metadata.c  |  19 +-
 .../ethernet/netronome/nfp/flower/offload.c   |  86 ++-
 .../netronome/nfp/flower/tunnel_conf.c        | 502 +++++++++---------
 5 files changed, 453 insertions(+), 267 deletions(-)

-- 
2.30.2