Messages in this thread | | | Date | Tue, 20 Aug 2019 12:01:40 +0200 | From | Antoine Tenart <> | Subject | Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure |
| |
Hi Sabrina,
On Fri, Aug 16, 2019 at 03:29:59PM +0200, Sabrina Dubroca wrote: > 2019-08-13, 16:18:40 +0000, Igor Russkikh wrote: > > On 13.08.2019 16:17, Andrew Lunn wrote: > > > 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. > > Agreed, I think an offload that cannot be disabled is quite problematic. > > > 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. > > +1 > > > 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. > > Yes, I think we need an offload on/off parameter (and IMO it should > probably be off by default). Then, if offloading is requested but > cannot be satisfied (unsupported key length, too many SAs, etc), or if > incompatible settings are requested (mixing offloaded and > non-offloaded SCs on a device that cannot do it), return an error. > > If we also export that offload parameter during netlink dumps, we can > inspect the state of the system, which helps for debugging.
So it seems the ability to enable or disable the offloading on a given interface is the main missing feature. I'll add that, however I'll probably (at least at first):
- Have the interface to be fully offloaded or fully handled in s/w (with errors being thrown if a given configuration isn't supported). Having both at the same time on a given interface would be tricky because of the MACsec validation parameter.
- Won't allow to enable/disable the offloading of there are rules in place, as we're not sure the same rules would be accepted by the other implementation.
I'm not sure if we should allow to mix the implementations on a given physical interface (by having two MACsec interfaces attached) as the validation would be impossible to do (we would have no idea if a packet was correctly handled by the offloading part or just not being a MACsec packet in the first place, in Rx).
I agree the offloading should be disabled by default, and only enabled by an user explicitly.
Thanks, Antoine
-- Antoine Ténart, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
| |