Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp923313imu; Wed, 23 Jan 2019 08:00:32 -0800 (PST) X-Google-Smtp-Source: ALg8bN7h/zS5rO/dMYvYs2USwjwlho0O1IkNHccYC2Wwwxpq4PrP3/XxHoFCNVGQm7/UXwNDMN6q X-Received: by 2002:a63:6c48:: with SMTP id h69mr2336872pgc.139.1548259232859; Wed, 23 Jan 2019 08:00:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548259232; cv=none; d=google.com; s=arc-20160816; b=sqkQykJUqwPtuOCRXVpkA8gkCETYa+9Ss8F3rWXjPEwWXgs66prAVdTThApxsP1naK zlszW2x+K/ZtDia4xw7j4Pter0lcSBnMvd+QZyer/PbeLzGX5Fw3E+TZ2oUi+UMNW5lr zvJH03wP5+DPhl7YdMzPTYgFq7XESSqFXZkQDd5rAvuejP/4XjNtGQy7CqNn348ZaAY5 RwQRURjVhipY7W2+XNmwVDDxJo6jX6tV0Dzx/EtKMdcFjfsEyJkiNHVj7bo5bUGP19DW tmI5S4C1W3DMEAacFRKMnTQeyLhjtsVEAukkBIRDB+zJ7FnWTxrRs4OlgYsXYj315/Lq ucSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=LzMOT30ESQ3GG88P+/AQeLl6aFme1UeJN+o/iRXZTkw=; b=eYkWvohOW1kUgwDltrlTwURv3GAgK4cwUgJRwL8oLa+CRKBk69cWIZOKGzzwU+Lp1c B1cWqtzDzMEOlp8oYMHoSDP/I2Plz+XvC8PDFXXga22RMHHHy6lFbL4YUVvLyFfC5hNf upzC8Ss/Yuc3mx51paGqKwQITumAzapj3I/z1c7ZqJ4b37vsxyjiwK3GZNiwffN4OM4n rqTx9rCilKoO2e4qdQcfwXHAcUGPDd7kU/lZoFt21kejM1cRi+4YsJ7a+gn9RXiZJ7um KFaaOgKuIWgHYOwbjwwpeAU0FulOcVfrisCoqagQLYNU7GAWAsd5SFBDUEzIiqUMwlNR +iBQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r39si19326887pld.434.2019.01.23.08.00.17; Wed, 23 Jan 2019 08:00:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726684AbfAWP7I (ORCPT + 99 others); Wed, 23 Jan 2019 10:59:08 -0500 Received: from mail.bootlin.com ([62.4.15.54]:42224 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbfAWP7H (ORCPT ); Wed, 23 Jan 2019 10:59:07 -0500 Received: by mail.bootlin.com (Postfix, from userid 110) id 657D02084E; Wed, 23 Jan 2019 16:59:05 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.2 Received: from localhost (aaubervilliers-681-1-87-206.w90-88.abo.wanadoo.fr [90.88.29.206]) by mail.bootlin.com (Postfix) with ESMTPSA id 29EB1209B6; Wed, 23 Jan 2019 16:58:55 +0100 (CET) From: Antoine Tenart To: davem@davemloft.net, sd@queasysnail.net, andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com Cc: Antoine Tenart , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, alexandre.belloni@bootlin.com, quentin.schulz@bootlin.com, allan.nielsen@microchip.com Subject: [PATCH net-next 00/10] net: macsec: initial support for hardware offloading Date: Wed, 23 Jan 2019 16:56:28 +0100 Message-Id: <20190123155638.13852-1-antoine.tenart@bootlin.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, This series intends to add support for offloading MACsec transformations in hardware enabled devices. The series is divided in two parts: the first 7 patches add the infrastructure support to offload a MACsec configuration to hardware drivers; and the last 3 patches introduce the MACsec offloading support in the Microsemi Ocelot networking PHY, making it the first driver to support the MACsec hardware offloading feature. The series can also be found at: https://github.com/atenart/linux/tree/net-next/macsec If you think I'm missing anyone who would be interested in participating to the discussion please feel free to Cc them and I'll add them to the Cc list for the next iteration. MACsec hardware offloading infrastructure ----------------------------------------- Linux has a software implementation of the MACsec standard and so far no hardware offloading feature was developed and submitted. Some hardware engines can perform MACsec operations, such as the Intel ixgbe NIC and the Microsemi Ocelot PHY (the one we use in this series). This means the MACsec offloading infrastructure should support networking PHY and Ethernet drivers. A preliminary email[1] was sent about this. The main idea here is to re-use the logic and data structures of the software MACsec implementation. This allows not to duplicate definitions and structure storing the same kind of information. It also allows to use a unified genlink interface for both MACsec implementations (so that the same userspace tool, `ip macsec`, is used with the same arguments). The MACsec offloading support cannot be disabled if an interface supports it at the moment, but this could be implemented later on if this is a need (we could think of something like `ip macsec set macsec0 offloading off`). The MACsec configuration is passed to device drivers supporting it through macsec_hw_offload() which is called (indirectly) from the MACsec genl helpers. This function calls the macsec() ops of PHY and Ethernet drivers in two steps: a preparation one, and a commit one. The first step is allowed to fail and should be used to check if a provided configuration is compatible with the features provided by a MACsec engine, while the second step is not allowed to fail and should only be used to enable a given MACsec configuration. Two extra calls are made: when a virtual MACsec interface is created and when it is deleted, so that the hardware driver can stay in sync. The Rx and TX handlers are modified to take in account the special case were the MACsec transformation happens in the hardware, whether in a PHY or in a MAC, as the packets seen by the networking stack on both the physical and MACsec virtual interface are exactly the same. This leads to some limitations: the hardware and software implementations can't be used on the same physical interface, as the policies would be impossible to fulfill (such as strict validation of the frames). Also only a single virtual MACsec interface can be attached to a physical port supporting hardware offloading as it would be impossible to guess onto which interface a given packet should go (for ingress traffic). Another limitation as of now is that the counters and statistics are not reported back from the hardware to the software MACsec implementation. This isn't an issue when using offloaded MACsec transformations, but it should be added in the future so that the MACsec state can be reported to the user (which would also improve the debug). [1] https://www.spinics.net/lists/netdev/msg513047.html Microsemi Ocelot PHY MACsec support ----------------------------------- In order to add support for the MACsec offloading feature in the Microsemi Ocelot driver, the __phy_read_page and __phy_write_page helpers had to be exported. This is because the initialization of the PHY is done while holding the MDIO bus lock, and we need to change the page to configure the MACsec block. The support itself is then added in two patches. The first one adds support for configuring the MACsec block within the PHY, so that it is up, running and available for future configuration, but is not doing any modification on the traffic passing through the PHY. The second patch implements the phy_driver macsec() helper in the Microsemi Ocelot PHY driver, and introduce helpers to configure MACsec transformations and flows to match specific packets. Comments are of course welcomed. Thanks! Antoine Antoine Tenart (10): net: introduce the MACSEC netdev feature net: macsec: convert to SPDX net: macsec: move some definitions in a dedicated header net: macsec: introduce the netdev_macsec structure net: phy: introduce a phy_driver macsec helper net: introduce a net_device_ops macsec helper net: macsec: hardware offloading infrastructure net: phy: export __phy_read_page/__phy_write_page net: phy: mscc: macsec initialization net: phy: mscc: macsec support drivers/net/macsec.c | 466 +++++++++------ drivers/net/phy/Kconfig | 2 + drivers/net/phy/mscc.c | 960 +++++++++++++++++++++++++++++++ drivers/net/phy/mscc_fc_buffer.h | 64 +++ drivers/net/phy/mscc_mac.h | 159 +++++ drivers/net/phy/mscc_macsec.h | 258 +++++++++ drivers/net/phy/phy-core.c | 6 +- drivers/net/phy/phy.c | 17 + include/linux/netdev_features.h | 3 + include/linux/netdevice.h | 8 + include/linux/phy.h | 12 + include/net/macsec.h | 223 +++++++ net/core/ethtool.c | 1 + 13 files changed, 1996 insertions(+), 183 deletions(-) create mode 100644 drivers/net/phy/mscc_fc_buffer.h create mode 100644 drivers/net/phy/mscc_mac.h create mode 100644 drivers/net/phy/mscc_macsec.h create mode 100644 include/net/macsec.h -- 2.20.1