[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <PH0PR12MB5449EED9BF691A80E9414E54BFC69@PH0PR12MB5449.namprd12.prod.outlook.com>
Date: Mon, 9 May 2022 06:41:49 +0000
From: Lior Nahmanson <liorna@...dia.com>
To: Leon Romanovsky <leon@...nel.org>
CC: "edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next v1 00/3] Introduce MACsec offload SKB extension
> On Sun, May 08, 2022 at 12:09:51PM +0300, Lior Nahmanson wrote:
> > This patchset introduces MACsec SKB extension to lay the ground for
> > MACsec HW offload.
> >
> > MACsec is an IEEE standard (IEEE 802.1AE) for MAC security.
> > It defines a way to establish a protocol independent connection
> > between two hosts with data confidentiality, authenticity and/or
> > integrity, using GCM-AES. MACsec operates on the Ethernet layer and as
> > such is a layer 2 protocol, which means it’s designed to secure
> > traffic within a layer 2 network, including DHCP or ARP requests.
> >
> > Linux has a software implementation of the MACsec standard and HW
> > offloading support.
> > The offloading is re-using the logic, netlink API and data structures
> > of the existing MACsec software implementation.
> >
> > For Tx:
> > In the current MACsec offload implementation, MACsec interfaces are
> > sharing the same MAC address of their parent interface by default.
> > Therefore, HW can't distinguish if a packet was sent from MACsec
> > interface and need to be offloaded or not.
> > Also, it can't distinguish from which MACsec interface it was sent in
> > case there are multiple MACsec interface with the same MAC address.
> >
> > Used SKB extension, so SW can mark if a packet is needed to be
> > offloaded and use the SCI, which is unique value for each MACsec
> > interface, to notify the HW from which MACsec interface the packet is
> sent.
> >
> > For Rx:
> > Like in the Tx changes, packet that don't have SecTAG header aren't
> > necessary been offloaded by the HW.
> > Therefore, the MACsec driver needs to distinguish if the packet was
> > offloaded or not and handle accordingly.
> > Moreover, if there are more than one MACsec device with the same MAC
> > address as in the packet's destination MAC, the packet will forward
> > only to this device and only to the desired one.
> >
> > Used SKB extension and marking it by the HW if the packet was
> > offloaded and to which MACsec offload device it belongs according to
> > the packet's SCI.
> >
> > 1) patch 0001-0002, Add support to SKB extension in MACsec code:
> > net/macsec: Add MACsec skb extension Tx Data path support
> > net/macsec: Add MACsec skb extension Rx Data path support
> >
> > 2) patch 0003, Move some MACsec driver code for sharing with various
> > drivers that implements offload:
> > net/macsec: Move some code for sharing with various drivers that
> > implements offload
>
> Can you please post diffstat and patch list of the series?
> As a reply to this cover letter.
>
> As an example:
> https://lore.kernel.org/netdev/20220508153049.427227-1-
> andrew@...n.ch/T/#m3c6fbfaa6c4e8c841e8bbb7e8953daefd2a53cd9
>
> Thanks
Lior Nahmanson (3):
net/macsec: Add MACsec skb extension Tx Data path support
net/macsec: Add MACsec skb extension Rx Data path support
net/macsec: Move some code for sharing with various drivers that
implements offload
drivers/net/Kconfig | 1 +
drivers/net/macsec.c | 45 +++++++++++++++++-------------------------
include/linux/skbuff.h | 3 +++
include/net/macsec.h | 26 ++++++++++++++++++++++++
net/core/skbuff.c | 7 +++++++
5 files changed, 55 insertions(+), 27 deletions(-)
Powered by blists - more mailing lists