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
