Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp517278ybl; Wed, 14 Aug 2019 01:32:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqwmxQpxNVNCXFUWFaiL1tC3YHPOKYuTWjgGNCLnjKS3vsOK5DnIbBJ2Zs7BTBvc9Zyb1PEm X-Received: by 2002:a63:b46:: with SMTP id a6mr38639634pgl.235.1565771578004; Wed, 14 Aug 2019 01:32:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565771577; cv=none; d=google.com; s=arc-20160816; b=lfZHzFad2IBOajMVJBik6jjt83UmQq0sV3k9QYQTCL8FHrsnOznop6q7ze8GYqfZ9a hEpbzarZAQXbfdXbDHTBFmzHDBtewLpYwVFB8vqFqtpvXfSkjBZ1GKeNEF3HNQcW/pGj ERgQa6kdt1LCugs16VlmPnuoqMm6/MgvrXsGnG9ADP9fchQ2OKZM82pH2A1aRr4Cisxn VidOk7C1L5ihCwyQAG1z9S3VhbmAqbAWWB2q2zEjYw7GS3TLSIvCSkDeLeOxBiaE7l3w sj5iiGehy9HDYSikBFK7yA7+XwC9HLsJD3eUN+xBAeqeZgdkdCqtW+7/3w6cvndrrray 6xQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=zRZGHX7iWb22+HGlqMphw3oeEytTKWVMr1qe2WcAFEg=; b=TT3Z5vOH6r8JQF591/jTIrQYFsKxpbg1TC3v6jxOppk6hosA4sebBnip2AQ5YbasAx lbyUgIa//fNMmIgk1X8ylQ4EzKE7nx/lnCfJuqBQ1q9L9YHxecZQISGbLHbhqGmfc7f5 ljXNrL9o0JjWTb9kB5T64j/Z1Aax4ZpZ+WKar9sCEm0WItM7rVvwOKkWOHq+zvqVN6GJ jrDDVKx0dN+bWVk1vx4WV3+6vElw09iu8Qxv3g4EBp7MU7eOO0dBZzyDAagkYYQ0Es7g dxX2aGIKaVcntoZ5PcRJZiXzv2YAAYtnizSuHX4MKZWOWd0fMdGFJTPgSSlLIqMriYSv C4uw== 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 q13si13717175plr.158.2019.08.14.01.32.39; Wed, 14 Aug 2019 01:32:57 -0700 (PDT) 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 S1727465AbfHNIbm (ORCPT + 99 others); Wed, 14 Aug 2019 04:31:42 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:42159 "EHLO relay7-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725265AbfHNIbl (ORCPT ); Wed, 14 Aug 2019 04:31:41 -0400 X-Originating-IP: 86.250.200.211 Received: from localhost (lfbn-1-17395-211.w86-250.abo.wanadoo.fr [86.250.200.211]) (Authenticated sender: antoine.tenart@bootlin.com) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 88B9F2000B; Wed, 14 Aug 2019 08:31:38 +0000 (UTC) Date: Wed, 14 Aug 2019 10:31:38 +0200 From: Antoine Tenart To: Igor Russkikh Cc: Andrew Lunn , Antoine Tenart , "davem@davemloft.net" , "sd@queasysnail.net" , "f.fainelli@gmail.com" , "hkallweit1@gmail.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "thomas.petazzoni@bootlin.com" , "alexandre.belloni@bootlin.com" , "allan.nielsen@microchip.com" , "camelia.groza@nxp.com" , Simon Edelhaus , Pavel Belous Subject: Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure Message-ID: <20190814083138.GE3200@kwain> References: <20190808140600.21477-1-antoine.tenart@bootlin.com> <20190808140600.21477-7-antoine.tenart@bootlin.com> <20190813085817.GA3200@kwain> <20190813131706.GE15047@lunn.ch> <2e3c2307-d414-a531-26cb-064e05fa01fc@aquantia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2e3c2307-d414-a531-26cb-064e05fa01fc@aquantia.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Igor, On Tue, Aug 13, 2019 at 04:18:40PM +0000, Igor Russkikh wrote: > On 13.08.2019 16:17, Andrew Lunn wrote: > > On Tue, Aug 13, 2019 at 10:58:17AM +0200, Antoine Tenart wrote: > >> I think this question is linked to the use of a MACsec virtual interface > >> when using h/w offloading. The starting point for me was that I wanted > >> to reuse the data structures and the API exposed to the userspace by the > >> s/w implementation of MACsec. I then had two choices: keeping the exact > >> same interface for the user (having a virtual MACsec interface), or > >> registering the MACsec genl ops onto the real net devices (and making > >> the s/w implementation a virtual net dev and a provider of the MACsec > >> "offloading" ops). > >> > >> The advantages of the first option were that nearly all the logic of the > >> s/w implementation could be kept and especially that it would be > >> transparent for the user to use both implementations of MACsec. > > > > We have always talked about offloading operations to the hardware, > > accelerating what the linux stack can do by making use of hardware > > accelerators. The basic user API should not change because of > > acceleration. Those are the general guidelines. > > > > It would however be interesting to get comments from those who did the > > software implementation and what they think of this architecture. I've > > no personal experience with MACSec, so it is hard for me to say if the > > current architecture makes sense when using accelerators. > > In terms of overall concepts, I'd add the following: > > 1) With current implementation it's impossible to install SW macsec engine onto > the device which supports HW offload. That could be a strong limitation in > cases when user sees HW macsec offload is broken or work differently, and he/she > wants to replace it with SW one. > MACSec is a complex feature, and it may happen something is missing in HW. > Trivial example is 256bit encryption, which is not always a musthave in HW > implementations. Agreed. I'm not sure it would be possible to have both used at the same time but there should be a way to switch between the two implementations. That is not supported for now, but I think that would be a good thing, and can probably come later on. > 2) I think, Antoine, its not totally true that otherwise the user macsec API > will be broken/changed. netlink api is the same, the only thing we may want to > add is an optional parameter to force selection of SW macsec engine. I meant that we can either have a virtual net device representing the MACsec feature and being the iface used to configure it, or we could have it only when s/w MACsec is used. That to me is part of the "API", or at least part of what's exposed to the user. > I'm also eager to hear from sw macsec users/devs on whats better here. I'd like more comments as well :) Thanks! Antoine -- Antoine T?nart, Bootlin Embedded Linux and Kernel engineering https://bootlin.com