From: Andrew Lunn <andrew@lunn.ch>
To: Antoine Tenart <antoine.tenart@bootlin.com>
Cc: davem@davemloft.net, sd@queasysnail.net, f.fainelli@gmail.com,
thomas.petazzoni@bootlin.com, alexandre.belloni@bootlin.com,
allan.nielsen@microsemi.com, netdev@vger.kernel.org,
jiri@resnulli.us
Subject: Re: MACsec hardware offloading
Date: Fri, 13 Jul 2018 18:20:02 +0200 [thread overview]
Message-ID: <20180713162002.GA4314@lunn.ch> (raw)
In-Reply-To: <20180713144608.GB2875@kwain>
On Fri, Jul 13, 2018 at 04:46:08PM +0200, Antoine Tenart wrote:
> Hello,
>
> Linux has a software implementation of the MACsec standard but so far,
> to my knowledge, no hardware offloading support was developed and sent
> upstream.
Mellonex is usually the leader in this sort of thing. Adding Jiri to
Cc: However, they often do their PHY control in firmware, rather than
using Linux.
> My main idea would be to reuse and leverage the actual software
> implementation in Linux. The advantages would be to reuse existing code,
> data structure and to configure this using the exact same tools from
> user-space.
I fully agree with this approach. That is how we do all other
offloading to accelerators.
> One important point about adding MACsec offloading in Linux is this can
> be done in either the MAC or the PHY. While I'll be working on making
> this work in a PHY, I know for sure some MAC do have the same capability
> (including for example the Intel ixgbe NIC).
I see in your current code, you check if the netdev has a phydev, and
if the phydev supports macsec, and then go straight to the phy. That
means there is no need to modify the MAC driver, it should just work.
If not, you call the MAC.
I would add support for the PHY to return -EOPNOTSUPP and then fall
back to trying the MAC.
Also, your current checks are
inconsistent. macsec_hw_offload_capable() checks for
phydev->drv->macsec, where as macsec_hw_offload() just checks for
dev->real_dev->phydev->drv. It looks like
dev->real_dev->phydev->drv->macsec could be a NULL pointer and bad
things happen.
For switchdev, when we offload to a switch, the switch nearly always
has the option to say it could not accept the offload. We then fall
back to performing the needed action in software. At the moment, i
don't see you checking the return code of macsec_hw_offload(). So it
is not clear to me if this software fallback works.
The Switchdev API is also transaction based, with a prepare and a
commit phase. All resource allocation happens in the prepare phase and
at this stage, you can return errors indicating offload is not
possible. The commit phase is not allowed to fail. You probably want
to go look at the mailing list archive and look at why this
architecture was decided on.
Maybe the MAC part of this should actually use the switchdev API? You
then get a lot of infrastructure for free.
Andrew
next prev parent reply other threads:[~2018-07-13 16:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-13 14:46 MACsec hardware offloading Antoine Tenart
2018-07-13 16:20 ` Andrew Lunn [this message]
2018-07-13 18:52 ` 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=20180713162002.GA4314@lunn.ch \
--to=andrew@lunn.ch \
--cc=alexandre.belloni@bootlin.com \
--cc=allan.nielsen@microsemi.com \
--cc=antoine.tenart@bootlin.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=jiri@resnulli.us \
--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).