mbox series

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

Message ID 20220505054348.269511-1-simon.horman@corigine.com (mailing list archive)
Headers show
Series nfp: flower: decap neighbour table rework | expand

Message

Simon Horman May 5, 2022, 5:43 a.m. UTC
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(-)

Comments

patchwork-bot+netdevbpf@kernel.org May 6, 2022, 10:40 a.m. UTC | #1
Hello:

This series was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:

On Thu,  5 May 2022 14:43:39 +0900 you wrote:
> 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.
> 
> [...]

Here is the summary with links:
  - [net-next,1/9] nfp: flower: add infrastructure for pre_tun rework
    https://git.kernel.org/netdev/net-next/c/29c691347e38
  - [net-next,2/9] nfp: flower: add/remove predt_list entries
    https://git.kernel.org/netdev/net-next/c/e30b2b68c14f
  - [net-next,3/9] nfp: flower: enforce more strict pre_tun checks
    https://git.kernel.org/netdev/net-next/c/38fc158e172b
  - [net-next,4/9] nfp: flower: fixup ipv6/ipv4 route lookup for neigh events
    https://git.kernel.org/netdev/net-next/c/9d5447ed44b5
  - [net-next,5/9] nfp: flower: update nfp_tun_neigh structs
    https://git.kernel.org/netdev/net-next/c/9ee7c42183d1
  - [net-next,6/9] nfp: flower: rework tunnel neighbour configuration
    https://git.kernel.org/netdev/net-next/c/f1df7956c11f
  - [net-next,7/9] nfp: flower: link pre_tun flow rules with neigh entries
    https://git.kernel.org/netdev/net-next/c/591c90a1d0b0
  - [net-next,8/9] nfp: flower: remove unused neighbour cache
    https://git.kernel.org/netdev/net-next/c/c83a0fbe9766
  - [net-next,9/9] nfp: flower: enable decap_v2 bit
    https://git.kernel.org/netdev/net-next/c/a7da2a864a4f

You are awesome, thank you!