On 8/13/19 9:28 AM, Andrew Lunn wrote: >> 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. > > Ideally, we want the driver to return EOPNOTSUPP if it does not > support something and the software implement should be used. > > If the offload is broken, we want a bug report! And if it works > differently, it suggests there is also a bug we need to fix, or the > standard is ambiguous. > > It would also be nice to add extra information to the netlink API to > indicate if HW or SW is being used. In other places where we offload > to accelerators we have such additional information.
Igor's point is entirely valid in that you should allow both offload to HW for what is possible and offload to a software implementation for what is not supported in HW. Let's an example that is hopefully more familiar to the people in this thread. Consider a NIC that can do single VLAN tag offload on xmit (or receive, does not matter), and you find yourself using a double VLAN tag configuration. You would create a first VLAN stacked network device which is fully offloaded onto the underlying NIC, and a second VLAN stacked network device on top of the first once which is not offloaded. The way I would imagine a MACsec offload is kind of similar here, in that it would be a macsec virtual network device on top of an underlying physical device. If no offload is possible, the virtual network device's xmit/receive path is used. If the NIC driver can offload it, it does not. How it does it, whether at the MAC/DMA level, or at the PHY level can be a check added at the appropriate level. -- Florian
