From patchwork Sat Sep 2 15:21:05 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiri Pirko X-Patchwork-Id: 809075 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=resnulli-us.20150623.gappssmtp.com header.i=@resnulli-us.20150623.gappssmtp.com header.b="YIfnoT+Q"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3xl0Fd1qyNz9sQl for ; Sun, 3 Sep 2017 01:21:40 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752716AbdIBPVc (ORCPT ); Sat, 2 Sep 2017 11:21:32 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38333 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752660AbdIBPVb (ORCPT ); Sat, 2 Sep 2017 11:21:31 -0400 Received: by mail-wm0-f54.google.com with SMTP id 187so15463720wmn.1 for ; Sat, 02 Sep 2017 08:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=dqIfuUUOU2mMah8HZm91S/U5IyCTd6RwRDIigPAPmi4=; b=YIfnoT+Qq9rDCYPXNNX0l+IrQTwjQ/UMGyjhglGerdr99JnIF1sdXCOD6+gxcYhwbh mcEP5IuYOpfyemf1A4SVmRiaeVDj/Xfwvg+Fw13vsH34XjY1kI5UgekIGZilDPGiX/MT Q0TRwIOb4C5l3BuLmOL1j5ehFXBymg7S0o2Yc2DznoPtH5ptF8GTxE6TjAiwpAKRcu3h LWhTxTn9hOuUmNWaiAv4C9d2cl+TV7jaHRrn3E/KsGr3JofcC4C8CrnBU0Vty7eciIzH Y/BRKZpBuyAgFfQx3/kWTfb+Isne7TuCSet56rokAponxZd9uDyzzvSI9TKD44eQhTk9 CRoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=dqIfuUUOU2mMah8HZm91S/U5IyCTd6RwRDIigPAPmi4=; b=Fy3bj9scN2aDv7Im11UtnyfknrwH0shbXX4aX3QqrIZpxIyjhtRtk8LMW1E4yq+Wpz UmN2817a8q9MsWZiHlvr5v7O10h0JXLx3OSqtSJOMBggHbx14jMRhBtWZEyWzM1S0dXQ 7rgJk16w6ixLGqBUfoUilLRtE/y+3coiNWbtcs/F0P+vkace/Bx30FpTZD3WDzNruQVX tBC3dEMjAc8YIScsMEvYTnIi2iyA/UIy7eCedTPKuhhEBl04UtN4Gy80uT/wuCRx7A3B ZjUEHu9PvJg/2n+nPN++PIAKQ+e+xhthPToJcwrE9P0afV/rXtSz/PuJ3dD+1IXq5YSz AluQ== X-Gm-Message-State: AHPjjUgEGtgDo2SgYZpTGkGCSp9PVp3GYGupblRSSUxf6lV7b/Gp8CLm 4E3BbxhD1PdPa7C6Y/A= X-Google-Smtp-Source: ADKCNb6ufWrVHLeexYlvHHdFMRyCXrXdFHBafZbs92O7ZStBdiV1uUCiOU1mRYusTlm4r1gLXSo5yQ== X-Received: by 10.28.209.13 with SMTP id i13mr1167257wmg.186.1504365689637; Sat, 02 Sep 2017 08:21:29 -0700 (PDT) Received: from localhost (jirka.pirko.cz. [84.16.102.26]) by smtp.gmail.com with ESMTPSA id u2sm151216wre.15.2017.09.02.08.21.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 02 Sep 2017 08:21:28 -0700 (PDT) From: Jiri Pirko To: netdev@vger.kernel.org Cc: davem@davemloft.net, petrm@mellanox.com, idosch@mellanox.com, mlxsw@mellanox.com Subject: [patch net-next 00/21] mlxsw: Offloading GRE tunnels Date: Sat, 2 Sep 2017 17:21:05 +0200 Message-Id: <20170902152126.17286-1-jiri@resnulli.us> X-Mailer: git-send-email 2.9.3 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Jiri Pirko Petr says: This patch series introduces to mlxsw driver support for offloading IP-in-IP tunnels in general, and for (subset of) GRE in particular. This patchset supports two ways of configuring GRE: - So called "hierarchical configuration", where the GRE device has a bound dummy device, which is in a different VRF. The VRF with host traffic is called "overlay", the one with encapsulated traffic is called "underlay". - So called "flat configuration", where the GRE device doesn't have a bound device, and overlay and underlay are both in the same VRF (possibly the default one). Two routes are then interesting: a route that directs traffic to a GRE device (which would typically be in overlay VRF, but could be in another one), and a local route for the tunnel's local address (in underlay). Handling of these two route types is then introduced as patches to support, respectively, IPv4 and IPv6 encapsulation and IPv4 decapsulation. The encap and decap routes then reference a loopback device, a new type of RIF introduced by this patchset for the specific use of offloading tunnels. The encap and decap code is abstract with respect to the particulars of individual L3 tunnel types. This patchset introduces support for GRE tunnels in particular. Limitations: - Each tunnel needs to have a different local address (within a given VRF). When two tunnels are used that are in conflict, FIB abort is triggered and the driver ceases offloading FIBs. Full handling of such configurations needs special setup in the hardware, such that the tunnels that share an address are dispatched correctly according to their key (or lack thereof). That's currently not implemented, and to keep things deterministic, the driver triggers FIB abort. - A next hop that uses an incompletely-specified tunnel (e.g. such that are used for LWT) is not offloaded, but doesn't trigger FIB abort like the above. If such routes end up being in a de facto conflict with other tunnels, then if there already is an offload for that address, the traffic for the conflicting tunnel will end up mismatching the configuration of the offloaded tunnel, and thus gets to slow path through an error trap. - GRE checksumming and sequence numbers are not supported and TTL and TOS need to be set to inherit. Tunnels with a different configuration are not offloaded and their traffic is trapping to slow path. Note in particular that TOS of inherit is not the default configuration and needs to be explicitly specified when the tunnel is created. - The only feature that is not graciously handled is that if a change is made to the tunnel, e.g. through "ip tunnel change", such changes are not reflected in the driver. There is currently no notification mechanism for these changes. Introduction of this mechanism and its leverage in the driver will be subject of follow-up work. For now this limitation can be worked around by removing and re-adding the encap route. Petr Machata (21): mlxsw: reg: Update RITR to support loopback device mlxsw: reg: Update RATR to support IP-in-IP tunnels mlxsw: reg: Move enum mlxsw_reg_ratr_trap_id mlxsw: reg: Add mlxsw_reg_ralue_act_ip2me_tun_pack() mlxsw: reg: Extract mlxsw_reg_ritr_mac_pack() mlxsw: reg: Give mlxsw_reg_ratr_pack a type parameter mlxsw: spectrum_router: Publish mlxsw_sp_l3proto mlxsw: spectrum_router: Add mlxsw_sp_ipip_ops mlxsw: spectrum_router: Support FID-less RIFs mlxsw: spectrum_router: Introduce loopback RIFs mlxsw: spectrum_router: Extract mlxsw_sp_fi_is_gateway() mlxsw: spectrum_router: Extract mlxsw_sp_rt6_is_gateway() mlxsw: spectrum_router: Make nexthops typed mlxsw: spectrum_router: Support IPv4 overlay encap mlxsw: spectrum_router: Support IPv6 overlay encap mlxsw: spectrum_router: Support IPv4 underlay decap mlxsw: spectrum_router: Use existing decap route mlxsw: spectrum: Register for IPIP_DECAP_ERROR trap mlxsw: spectrum_router: Add loopback accessors mlxsw: spectrum_router: Support GRE tunnels mlxsw: reg: Add Routing Tunnel Decap Properties Register drivers/net/ethernet/mellanox/mlxsw/Makefile | 4 +- drivers/net/ethernet/mellanox/mlxsw/reg.h | 311 ++++++- drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 1 + drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 + .../net/ethernet/mellanox/mlxsw/spectrum_ipip.c | 214 +++++ .../net/ethernet/mellanox/mlxsw/spectrum_ipip.h | 79 ++ .../net/ethernet/mellanox/mlxsw/spectrum_router.c | 947 +++++++++++++++++++-- .../net/ethernet/mellanox/mlxsw/spectrum_router.h | 28 + drivers/net/ethernet/mellanox/mlxsw/trap.h | 1 + 9 files changed, 1485 insertions(+), 101 deletions(-) create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.c create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_ipip.h