netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Antoine Tenart <antoine.tenart@bootlin.com>
Cc: Igor Russkikh <Igor.Russkikh@aquantia.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"sd@queasysnail.net" <sd@queasysnail.net>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"thomas.petazzoni@bootlin.com" <thomas.petazzoni@bootlin.com>,
	"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
	"allan.nielsen@microchip.com" <allan.nielsen@microchip.com>,
	"camelia.groza@nxp.com" <camelia.groza@nxp.com>,
	Simon Edelhaus <Simon.Edelhaus@aquantia.com>,
	Pavel Belous <Pavel.Belous@aquantia.com>
Subject: Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure
Date: Tue, 13 Aug 2019 15:17:06 +0200	[thread overview]
Message-ID: <20190813131706.GE15047@lunn.ch> (raw)
In-Reply-To: <20190813085817.GA3200@kwain>

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.

Hi Antoine

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.

	Andrew

  reply	other threads:[~2019-08-13 13:17 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-08 14:05 [PATCH net-next v2 0/9] net: macsec: initial support for hardware offloading Antoine Tenart
2019-08-08 14:05 ` [PATCH net-next v2 1/9] net: introduce the MACSEC netdev feature Antoine Tenart
2019-08-08 14:05 ` [PATCH net-next v2 2/9] net: macsec: move some definitions in a dedicated header Antoine Tenart
2019-08-10 12:19   ` Igor Russkikh
2019-08-12  8:17     ` Antoine Tenart
2019-08-08 14:05 ` [PATCH net-next v2 3/9] net: macsec: introduce the macsec_context structure Antoine Tenart
2019-08-08 14:05 ` [PATCH net-next v2 4/9] net: introduce MACsec ops and add a reference in net_device Antoine Tenart
2019-08-09 20:35   ` Jakub Kicinski
2019-08-12  8:18     ` Antoine Tenart
2019-08-08 14:05 ` [PATCH net-next v2 5/9] net: phy: add MACsec ops in phy_device Antoine Tenart
2019-08-14 23:15   ` Florian Fainelli
2019-08-20 10:07     ` Antoine Tenart
2019-08-08 14:05 ` [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure Antoine Tenart
2019-08-10 13:20   ` Igor Russkikh
2019-08-13  8:58     ` Antoine Tenart
2019-08-13 13:17       ` Andrew Lunn [this message]
2019-08-13 16:18         ` Igor Russkikh
2019-08-13 16:28           ` Andrew Lunn
2019-08-14  8:32             ` Antoine Tenart
2019-08-14 23:28             ` Florian Fainelli
2019-08-16 13:26             ` Sabrina Dubroca
2019-08-20 10:03             ` Antoine Tenart
2019-08-14  8:31           ` Antoine Tenart
2019-08-16 13:29           ` Sabrina Dubroca
2019-08-20 10:01             ` Antoine Tenart
2019-08-20 14:41               ` Sabrina Dubroca
2019-08-21  0:01                 ` Andrew Lunn
2019-08-21  9:20                 ` Igor Russkikh
2019-08-21  9:27                   ` allan.nielsen
2019-08-21  9:24                 ` allan.nielsen
2019-08-21 10:01                 ` Antoine Tenart
2019-08-21 12:01                   ` Igor Russkikh
2019-08-16 13:25       ` Sabrina Dubroca
2019-08-20 10:07         ` Antoine Tenart
2019-08-10 16:34   ` Andrew Lunn
2019-08-12  8:15     ` Antoine Tenart
2019-08-13 11:46     ` Igor Russkikh
2019-08-08 14:05 ` [PATCH net-next v2 7/9] net: phy: export __phy_read_page/__phy_write_page Antoine Tenart
2019-08-08 14:05 ` [PATCH net-next v2 8/9] net: phy: mscc: macsec initialization Antoine Tenart
2019-08-10 16:53   ` Andrew Lunn
2019-08-12  8:12     ` Antoine Tenart
2019-08-08 14:06 ` [PATCH net-next v2 9/9] net: phy: mscc: macsec support Antoine Tenart
2019-08-09 11:23 ` [PATCH net-next v2 0/9] net: macsec: initial support for hardware offloading Allan W. Nielsen
2019-08-09 11:40   ` Antoine Tenart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190813131706.GE15047@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=Igor.Russkikh@aquantia.com \
    --cc=Pavel.Belous@aquantia.com \
    --cc=Simon.Edelhaus@aquantia.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=allan.nielsen@microchip.com \
    --cc=antoine.tenart@bootlin.com \
    --cc=camelia.groza@nxp.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sd@queasysnail.net \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).