From: David S. Miller Date: Wed, 24 Mar 2021 23:34:58 +0000 (-0700) Subject: Merge branch 'mlxsw-resilient-nh-groups' X-Git-Tag: microblaze-v5.14~96^2~409 X-Git-Url: http://git.monstr.eu/?a=commitdiff_plain;h=eb9da2c1b60390802c48354f7d5c644c26a9e56f;p=linux-2.6-microblaze.git Merge branch 'mlxsw-resilient-nh-groups' Ido Schimmel says: ==================== mlxsw: Add support for resilient nexthop groups This patchset adds support for resilient nexthop groups in mlxsw. As far as the hardware is concerned, resilient groups are the same as regular groups. The differences lie in how mlxsw manages the individual adjacency entries (nexthop buckets) that make up the group. The first difference is that unlike regular groups the driver needs to periodically update the kernel about activity of nexthop buckets so that the kernel will not treat the buckets as idle, given traffic is offloaded from the CPU to the ASIC. This is similar to what mlxsw is already doing with respect to neighbour entries. The update interval is set to 1 second to allow for short idle timers. The second difference is that nexthop buckets that correspond to an unresolved neighbour must be programmed to the device, as the size of the group must remain fixed. This is achieved by programming such entries with trap action, in order to trigger neighbour resolution by the kernel. The third difference is atomic replacement of individual nexthop buckets. While the driver periodically updates the kernel about activity of nexthop buckets, it is possible for a bucket to become active just before the kernel decides to replace it with a different nexthop. To avoid such situations and connections being reset, the driver instructs the device to only replace an adjacency entry if it is inactive. Failures are propagated back to the nexthop code. Patchset overview: Patches #1-#7 gradually add support for resilient nexthop groups Patch #8 finally enables such groups to be programmed to the device Patches #9-#10 add mlxsw-specific selftests ==================== Signed-off-by: David S. Miller --- eb9da2c1b60390802c48354f7d5c644c26a9e56f