RE: Severe performance regression in "net: macsec: preserve ingress frame ordering"

From: "Van Leeuwen, Pascal" <pvanleeuwen@rambus.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Sabrina Dubroca <sd@queasysnail.net>,
	Scott Dial <scott@scottdial.com>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	Ryan Cox <ryan_cox@byu.edu>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	Antoine Tenart <antoine.tenart@bootlin.com>,
	"ebiggers@google.com" <ebiggers@google.com>
Subject: RE: Severe performance regression in "net: macsec: preserve ingress frame ordering"
Date: Tue, 25 Aug 2020 13:09:31 +0000	[thread overview]
Message-ID: <CY4PR0401MB3652AB8C5DC2FEA09A6F2BECC3570@CY4PR0401MB3652.namprd04.prod.outlook.com> (raw)
In-Reply-To: <20200824130142.GN2588906@lunn.ch>

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Monday, August 24, 2020 3:02 PM
> To: Van Leeuwen, Pascal <pvanleeuwen@rambus.com>
> Cc: Sabrina Dubroca <sd@queasysnail.net>; Scott Dial <scott@scottdial.com>; linux-crypto@vger.kernel.org; Ryan Cox
> <ryan_cox@byu.edu>; netdev@vger.kernel.org; davem@davemloft.net; Antoine Tenart <antoine.tenart@bootlin.com>;
> ebiggers@google.com
> Subject: Re: Severe performance regression in "net: macsec: preserve ingress frame ordering"
>
> <<< External Email >>>
> On Mon, Aug 24, 2020 at 09:07:26AM +0000, Van Leeuwen, Pascal wrote:
> > No need to point this out to me as we're the number one supplier of inline MACsec IP :-)
> > In fact, the Microsemi PHY solution you mention is ours, major parts of that design were
> > even created by these 2 hands here.
>
> Oh,  O.K.
>
> Do you know of other silicon vendors which are using the same IP?
>
I do, there are many. But unfortunately, I cannot disclose our customers unless this is already
public information, e.g. due to some press release or whatever.

> Maybe we can encourage them to share the driver, rather than re-invent
> the wheel, which often happens when nobody realises it is basically
> the same core with a different wrapper.
>
Yes, that could save a lot of duplication of code and effort. And it should be rather trivial to
move the MACsec stuff to a higher level as all it needs is some register access to PHY control
space and an interrupt callback. So it should be possible to define a simple API between the
MACsec driver and the PHY driver for that. I would expect a similar API to be useful for
MACsec enabled PHY's using other MACsec solutions (i.e. not ours) as well ...

The problem is: who will do it? We can't do it, because we have no access to the actual HW.
Microsemi won't be motivated to do it, because it would only help the competition, so why
would they? So it would have to be some competitor also desiring MACsec support (for the
same MACsec IP), convincing the maintainer of the Microsemi driver to go along with the
changes. I guess it's not all that relevant until we hit that situation.

> Thanks
> Andrew

Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953

Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.

** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **

Rambus Inc.<http://www.rambus.com>