| Message ID | cover.1665416630.git.sd@queasysnail.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | macsec: offload-related fixes | expand |
On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > I'm working on a dummy offload for macsec on netdevsim. It just has a > small SecY and RXSC table so I can trigger failures easily on the > ndo_* side. It has exposed a couple of issues. > > The first patch will cause some performance degradation, but in the > current state it's not possible to offload macsec to lower devices > that also support ipsec offload. Please don't, IPsec offload is available and undergoing review. https://lore.kernel.org/netdev/cover.1662295929.git.leonro@nvidia.com/ This is whole series (XFRM + driver) for IPsec full offload. https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=xfrm-next > I'm working on re-adding those feature flags when offload is available, > but I haven't fully solved that yet. So let's revert when you are ready. Thanks
2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > > I'm working on a dummy offload for macsec on netdevsim. It just has a > > small SecY and RXSC table so I can trigger failures easily on the > > ndo_* side. It has exposed a couple of issues. > > > > The first patch will cause some performance degradation, but in the > > current state it's not possible to offload macsec to lower devices > > that also support ipsec offload. > > Please don't, IPsec offload is available and undergoing review. > https://lore.kernel.org/netdev/cover.1662295929.git.leonro@nvidia.com/ > > This is whole series (XFRM + driver) for IPsec full offload. > https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=xfrm-next Yes, and that's not upstream yet. That patchset is also doing nothing to address the issue I'm refering to here, where xfrm_api_check rejects the macsec device because it has the NETIF_F_HW_ESP flag (passed from the lower device) and no xfrmdev_ops. OTOH the mlx5 driver has both macsec and ipsec offload already, so I think it should be affected by this exact issue. There are other feature flags that almost certainly shouldn't be copied from the lower device, such as the TLS offload flags.
On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote: > 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > > > I'm working on a dummy offload for macsec on netdevsim. It just has a > > > small SecY and RXSC table so I can trigger failures easily on the > > > ndo_* side. It has exposed a couple of issues. > > > > > > The first patch will cause some performance degradation, but in the > > > current state it's not possible to offload macsec to lower devices > > > that also support ipsec offload. > > > > Please don't, IPsec offload is available and undergoing review. > > https://lore.kernel.org/netdev/cover.1662295929.git.leonro@nvidia.com/ > > > > This is whole series (XFRM + driver) for IPsec full offload. > > https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=xfrm-next > > Yes, and that's not upstream yet. For this conversation, you can assume what that series is merged. It is not merged due to request to change how we store XFRM policies in XFRM core code. > That patchset is also doing nothing to address the issue I'm refering > to here, where xfrm_api_check rejects the macsec device because it has > the NETIF_F_HW_ESP flag (passed from the lower device) and no xfrmdev_ops. Of course, why do you think that IPsec series should address MACsec bugs? Thanks
Quoting Leon Romanovsky (2022-10-14 13:03:57) > On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote: > > 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > > > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > > > > I'm working on a dummy offload for macsec on netdevsim. It just has a > > > > small SecY and RXSC table so I can trigger failures easily on the > > > > ndo_* side. It has exposed a couple of issues. > > > > > > > > The first patch will cause some performance degradation, but in the > > > > current state it's not possible to offload macsec to lower devices > > > > that also support ipsec offload. > > > > > > Please don't, IPsec offload is available and undergoing review. > > > https://lore.kernel.org/netdev/cover.1662295929.git.leonro@nvidia.com/ > > > > > > This is whole series (XFRM + driver) for IPsec full offload. > > > https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=xfrm-next > > > That patchset is also doing nothing to address the issue I'm refering > > to here, where xfrm_api_check rejects the macsec device because it has > > the NETIF_F_HW_ESP flag (passed from the lower device) and no xfrmdev_ops. > > Of course, why do you think that IPsec series should address MACsec bugs? I was looking at this and the series LGTM. I don't get the above concern, can you clarify? If a lower device has both IPsec & MACsec offload capabilities: - Without the revert: IPsec can be offloaded to the lower dev, MACsec can't. That's a bug. - With the revert: IPsec and MACsec can be offloaded to the lower dev. Some features might not propagate to the MACsec dev, which won't allow some performance optimizations in the MACsec data path. Thanks, Antoine
2022-10-14, 14:03:57 +0300, Leon Romanovsky wrote: > On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote: > > 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > > > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > > > > I'm working on a dummy offload for macsec on netdevsim. It just has a > > > > small SecY and RXSC table so I can trigger failures easily on the > > > > ndo_* side. It has exposed a couple of issues. > > > > > > > > The first patch will cause some performance degradation, but in the > > > > current state it's not possible to offload macsec to lower devices > > > > that also support ipsec offload. > > > > > > Please don't, IPsec offload is available and undergoing review. > > > https://lore.kernel.org/netdev/cover.1662295929.git.leonro@nvidia.com/ > > > > > > This is whole series (XFRM + driver) for IPsec full offload. > > > https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=xfrm-next > > > > Yes, and that's not upstream yet. > > For this conversation, you can assume what that series is merged. > It is not merged due to request to change how we store XFRM policies > in XFRM core code. > > > That patchset is also doing nothing to address the issue I'm refering > > to here, where xfrm_api_check rejects the macsec device because it has > > the NETIF_F_HW_ESP flag (passed from the lower device) and no xfrmdev_ops. > > Of course, why do you think that IPsec series should address MACsec bugs? I don't. That's why I really don't understand how the "full offload" series is relevant for this patchset.
On Fri, Oct 14, 2022 at 04:03:56PM +0200, Antoine Tenart wrote: > Quoting Leon Romanovsky (2022-10-14 13:03:57) > > On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote: > > > 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > > > > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > > > > > I'm working on a dummy offload for macsec on netdevsim. It just has a > > > > > small SecY and RXSC table so I can trigger failures easily on the > > > > > ndo_* side. It has exposed a couple of issues. > > > > > > > > > > The first patch will cause some performance degradation, but in the > > > > > current state it's not possible to offload macsec to lower devices > > > > > that also support ipsec offload. > > > > > > > > Please don't, IPsec offload is available and undergoing review. > > > > https://lore.kernel.org/netdev/cover.1662295929.git.leonro@nvidia.com/ > > > > > > > > This is whole series (XFRM + driver) for IPsec full offload. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=xfrm-next > > > > > That patchset is also doing nothing to address the issue I'm refering > > > to here, where xfrm_api_check rejects the macsec device because it has > > > the NETIF_F_HW_ESP flag (passed from the lower device) and no xfrmdev_ops. > > > > Of course, why do you think that IPsec series should address MACsec bugs? > > I was looking at this and the series LGTM. I don't get the above > concern, can you clarify? > > If a lower device has both IPsec & MACsec offload capabilities: > > - Without the revert: IPsec can be offloaded to the lower dev, MACsec > can't. That's a bug. And how does it possible that mlx5 macsec offload work? > > - With the revert: IPsec and MACsec can be offloaded to the lower dev. > Some features might not propagate to the MACsec dev, which won't allow > some performance optimizations in the MACsec data path. My concern is related to this sentence: "it's not possible to offload macsec to lower devices that also support ipsec offload", because our devices support both macsec and IPsec offloads at the same time. I don't want to see anything (even in commit messages) that assumes that IPsec offload doesn't exist. Thanks > > Thanks, > Antoine
2022-10-18, 09:28:08 +0300, Leon Romanovsky wrote: > On Fri, Oct 14, 2022 at 04:03:56PM +0200, Antoine Tenart wrote: > > Quoting Leon Romanovsky (2022-10-14 13:03:57) > > > On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote: > > > > 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > > > > > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > > > > > > I'm working on a dummy offload for macsec on netdevsim. It just has a > > > > > > small SecY and RXSC table so I can trigger failures easily on the > > > > > > ndo_* side. It has exposed a couple of issues. > > > > > > > > > > > > The first patch will cause some performance degradation, but in the > > > > > > current state it's not possible to offload macsec to lower devices > > > > > > that also support ipsec offload. > > > > > > > > > > Please don't, IPsec offload is available and undergoing review. > > > > > https://lore.kernel.org/netdev/cover.1662295929.git.leonro@nvidia.com/ > > > > > > > > > > This is whole series (XFRM + driver) for IPsec full offload. > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=xfrm-next > > > > > > > That patchset is also doing nothing to address the issue I'm refering > > > > to here, where xfrm_api_check rejects the macsec device because it has > > > > the NETIF_F_HW_ESP flag (passed from the lower device) and no xfrmdev_ops. > > > > > > Of course, why do you think that IPsec series should address MACsec bugs? > > > > I was looking at this and the series LGTM. I don't get the above > > concern, can you clarify? > > > > If a lower device has both IPsec & MACsec offload capabilities: > > > > - Without the revert: IPsec can be offloaded to the lower dev, MACsec > > can't. That's a bug. > > And how does it possible that mlx5 macsec offload work? Well, I don't know. AFAICT, xfrm_api_check will be called for every new net_device created in the system, so a new macsec device with NETIF_F_HW_ESP will be rejected. Am I missing something? I don't have access to mlx5 NICs with macsec offload so I can't check how that would work. My guess is that for some reason, the mlx5 driver didn't expose the NETIF_F_HW_ESP feature (CONFIG_MLX5_EN_IPSEC=n?). The only other possibility I see is CONFIG_XFRM=n. > > > > > - With the revert: IPsec and MACsec can be offloaded to the lower dev. > > Some features might not propagate to the MACsec dev, which won't allow > > some performance optimizations in the MACsec data path. > > My concern is related to this sentence: "it's not possible to offload macsec > to lower devices that also support ipsec offload", because our devices support > both macsec and IPsec offloads at the same time. > > I don't want to see anything (even in commit messages) that assumes that IPsec > offload doesn't exist. I don't understand what you're saying here. Patch #1 from this series is exactly about the macsec device acknowledging that ipsec offload exists. The rest of the patches is strictly macsec stuff and says nothing about ipsec. Can you point out where, in this series, I'm claiming that ipsec offload doesn't exist?
On Thu, Oct 20, 2022 at 03:54:28PM +0200, Sabrina Dubroca wrote: > 2022-10-18, 09:28:08 +0300, Leon Romanovsky wrote: > > On Fri, Oct 14, 2022 at 04:03:56PM +0200, Antoine Tenart wrote: > > > Quoting Leon Romanovsky (2022-10-14 13:03:57) > > > > On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote: > > > > > 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > > > > > > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: <...> > > > - With the revert: IPsec and MACsec can be offloaded to the lower dev. > > > Some features might not propagate to the MACsec dev, which won't allow > > > some performance optimizations in the MACsec data path. > > > > My concern is related to this sentence: "it's not possible to offload macsec > > to lower devices that also support ipsec offload", because our devices support > > both macsec and IPsec offloads at the same time. > > > > I don't want to see anything (even in commit messages) that assumes that IPsec > > offload doesn't exist. > > I don't understand what you're saying here. Patch #1 from this series > is exactly about the macsec device acknowledging that ipsec offload > exists. The rest of the patches is strictly macsec stuff and says > nothing about ipsec. Can you point out where, in this series, I'm > claiming that ipsec offload doesn't exist? All this conversation is about one sentence, which I cited above - "it's not possible to offload macsec to lower devices that also support ipsec offload". From the comments, I think that you wanted to say "macsec offload is not working due to performance optimization, where IPsec offload feature flag was exposed from lower device." Did I get it correctly, now? Thanks > > -- > Sabrina >
2022-10-23, 10:52:56 +0300, Leon Romanovsky wrote: > On Thu, Oct 20, 2022 at 03:54:28PM +0200, Sabrina Dubroca wrote: > > 2022-10-18, 09:28:08 +0300, Leon Romanovsky wrote: > > > On Fri, Oct 14, 2022 at 04:03:56PM +0200, Antoine Tenart wrote: > > > > Quoting Leon Romanovsky (2022-10-14 13:03:57) > > > > > On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote: > > > > > > 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > > > > > > > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > > <...> > > > > > - With the revert: IPsec and MACsec can be offloaded to the lower dev. > > > > Some features might not propagate to the MACsec dev, which won't allow > > > > some performance optimizations in the MACsec data path. > > > > > > My concern is related to this sentence: "it's not possible to offload macsec > > > to lower devices that also support ipsec offload", because our devices support > > > both macsec and IPsec offloads at the same time. > > > > > > I don't want to see anything (even in commit messages) that assumes that IPsec > > > offload doesn't exist. > > > > I don't understand what you're saying here. Patch #1 from this series > > is exactly about the macsec device acknowledging that ipsec offload > > exists. The rest of the patches is strictly macsec stuff and says > > nothing about ipsec. Can you point out where, in this series, I'm > > claiming that ipsec offload doesn't exist? > > All this conversation is about one sentence, which I cited above - "it's not possible > to offload macsec to lower devices that also support ipsec offload". From the comments, > I think that you wanted to say "macsec offload is not working due to performance > optimization, where IPsec offload feature flag was exposed from lower device." Did I get > it correctly, now? Yes. "In the current state" (that I wrote in front of the sentence you quoted) refers to the changes introduced by commit c850240b6c41. The details are present in the commit message for patch 1. Do you object to the revert, if I rephrase the justification, and then re-add the features that make sense in net-next?
On Mon, Oct 24, 2022 at 10:24:28AM +0200, Sabrina Dubroca wrote: > 2022-10-23, 10:52:56 +0300, Leon Romanovsky wrote: > > On Thu, Oct 20, 2022 at 03:54:28PM +0200, Sabrina Dubroca wrote: > > > 2022-10-18, 09:28:08 +0300, Leon Romanovsky wrote: > > > > On Fri, Oct 14, 2022 at 04:03:56PM +0200, Antoine Tenart wrote: > > > > > Quoting Leon Romanovsky (2022-10-14 13:03:57) > > > > > > On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote: > > > > > > > 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > > > > > > > > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > > > > <...> > > > > > > > - With the revert: IPsec and MACsec can be offloaded to the lower dev. > > > > > Some features might not propagate to the MACsec dev, which won't allow > > > > > some performance optimizations in the MACsec data path. > > > > > > > > My concern is related to this sentence: "it's not possible to offload macsec > > > > to lower devices that also support ipsec offload", because our devices support > > > > both macsec and IPsec offloads at the same time. > > > > > > > > I don't want to see anything (even in commit messages) that assumes that IPsec > > > > offload doesn't exist. > > > > > > I don't understand what you're saying here. Patch #1 from this series > > > is exactly about the macsec device acknowledging that ipsec offload > > > exists. The rest of the patches is strictly macsec stuff and says > > > nothing about ipsec. Can you point out where, in this series, I'm > > > claiming that ipsec offload doesn't exist? > > > > All this conversation is about one sentence, which I cited above - "it's not possible > > to offload macsec to lower devices that also support ipsec offload". From the comments, > > I think that you wanted to say "macsec offload is not working due to performance > > optimization, where IPsec offload feature flag was exposed from lower device." Did I get > > it correctly, now? > > Yes. "In the current state" (that I wrote in front of the sentence you > quoted) refers to the changes introduced by commit c850240b6c41. The > details are present in the commit message for patch 1. > > Do you object to the revert, if I rephrase the justification, and then > re-add the features that make sense in net-next? I don't have any objections. Thanks > > -- > Sabrina >
2022-10-24, 11:43:26 +0300, Leon Romanovsky wrote: > On Mon, Oct 24, 2022 at 10:24:28AM +0200, Sabrina Dubroca wrote: > > 2022-10-23, 10:52:56 +0300, Leon Romanovsky wrote: > > > On Thu, Oct 20, 2022 at 03:54:28PM +0200, Sabrina Dubroca wrote: > > > > 2022-10-18, 09:28:08 +0300, Leon Romanovsky wrote: > > > > > On Fri, Oct 14, 2022 at 04:03:56PM +0200, Antoine Tenart wrote: > > > > > > Quoting Leon Romanovsky (2022-10-14 13:03:57) > > > > > > > On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote: > > > > > > > > 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > > > > > > > > > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > > > > > > <...> > > > > > > > > > - With the revert: IPsec and MACsec can be offloaded to the lower dev. > > > > > > Some features might not propagate to the MACsec dev, which won't allow > > > > > > some performance optimizations in the MACsec data path. > > > > > > > > > > My concern is related to this sentence: "it's not possible to offload macsec > > > > > to lower devices that also support ipsec offload", because our devices support > > > > > both macsec and IPsec offloads at the same time. > > > > > > > > > > I don't want to see anything (even in commit messages) that assumes that IPsec > > > > > offload doesn't exist. > > > > > > > > I don't understand what you're saying here. Patch #1 from this series > > > > is exactly about the macsec device acknowledging that ipsec offload > > > > exists. The rest of the patches is strictly macsec stuff and says > > > > nothing about ipsec. Can you point out where, in this series, I'm > > > > claiming that ipsec offload doesn't exist? > > > > > > All this conversation is about one sentence, which I cited above - "it's not possible > > > to offload macsec to lower devices that also support ipsec offload". From the comments, > > > I think that you wanted to say "macsec offload is not working due to performance > > > optimization, where IPsec offload feature flag was exposed from lower device." Did I get > > > it correctly, now? > > > > Yes. "In the current state" (that I wrote in front of the sentence you > > quoted) refers to the changes introduced by commit c850240b6c41. The > > details are present in the commit message for patch 1. > > > > Do you object to the revert, if I rephrase the justification, and then > > re-add the features that make sense in net-next? > > I don't have any objections. Would this be ok for the cover letter? ---- The first patch is a revert of commit c850240b6c41 ("net: macsec: report real_dev features when HW offloading is enabled"). That commit tried to improve the performance of macsec offload by taking advantage of some of the NIC's features, but in doing so, broke macsec offload when the lower device supports both macsec and ipsec offload, as the ipsec offload feature flags were copied from the real device. Since the macsec device doesn't provide xdo_* ops, the XFRM core rejects the registration of the new macsec device in xfrm_api_check. I'm working on re-adding those feature flags when offload is available, but I haven't fully solved that yet. I think it would be safer to do that second part in net-next considering how complex feature interactions tend to be. ---- Do you want something added to the commit message of the revert as well? Thanks.
On Tue, Oct 25, 2022 at 12:05:02AM +0200, Sabrina Dubroca wrote: > 2022-10-24, 11:43:26 +0300, Leon Romanovsky wrote: > > On Mon, Oct 24, 2022 at 10:24:28AM +0200, Sabrina Dubroca wrote: > > > 2022-10-23, 10:52:56 +0300, Leon Romanovsky wrote: > > > > On Thu, Oct 20, 2022 at 03:54:28PM +0200, Sabrina Dubroca wrote: > > > > > 2022-10-18, 09:28:08 +0300, Leon Romanovsky wrote: > > > > > > On Fri, Oct 14, 2022 at 04:03:56PM +0200, Antoine Tenart wrote: > > > > > > > Quoting Leon Romanovsky (2022-10-14 13:03:57) > > > > > > > > On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote: > > > > > > > > > 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote: > > > > > > > > > > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote: > > > > > > > > <...> > > > > > > > > > > > - With the revert: IPsec and MACsec can be offloaded to the lower dev. > > > > > > > Some features might not propagate to the MACsec dev, which won't allow > > > > > > > some performance optimizations in the MACsec data path. > > > > > > > > > > > > My concern is related to this sentence: "it's not possible to offload macsec > > > > > > to lower devices that also support ipsec offload", because our devices support > > > > > > both macsec and IPsec offloads at the same time. > > > > > > > > > > > > I don't want to see anything (even in commit messages) that assumes that IPsec > > > > > > offload doesn't exist. > > > > > > > > > > I don't understand what you're saying here. Patch #1 from this series > > > > > is exactly about the macsec device acknowledging that ipsec offload > > > > > exists. The rest of the patches is strictly macsec stuff and says > > > > > nothing about ipsec. Can you point out where, in this series, I'm > > > > > claiming that ipsec offload doesn't exist? > > > > > > > > All this conversation is about one sentence, which I cited above - "it's not possible > > > > to offload macsec to lower devices that also support ipsec offload". From the comments, > > > > I think that you wanted to say "macsec offload is not working due to performance > > > > optimization, where IPsec offload feature flag was exposed from lower device." Did I get > > > > it correctly, now? > > > > > > Yes. "In the current state" (that I wrote in front of the sentence you > > > quoted) refers to the changes introduced by commit c850240b6c41. The > > > details are present in the commit message for patch 1. > > > > > > Do you object to the revert, if I rephrase the justification, and then > > > re-add the features that make sense in net-next? > > > > I don't have any objections. > > Would this be ok for the cover letter? > > ---- > The first patch is a revert of commit c850240b6c41 ("net: macsec: > report real_dev features when HW offloading is enabled"). That > commit tried to improve the performance of macsec offload by > taking advantage of some of the NIC's features, but in doing so, > broke macsec offload when the lower device supports both macsec > and ipsec offload, as the ipsec offload feature flags were copied > from the real device. Since the macsec device doesn't provide > xdo_* ops, the XFRM core rejects the registration of the new > macsec device in xfrm_api_check. > > I'm working on re-adding those feature flags when offload is > available, but I haven't fully solved that yet. I think it would > be safer to do that second part in net-next considering how > complex feature interactions tend to be. > ---- > > Do you want something added to the commit message of the revert as > well? It will be great to see this sentence "commit tried to improve ... device in xfrm_api_check." in that revert patch. It makes everything clearer. Thanks
I'm working on a dummy offload for macsec on netdevsim. It just has a small SecY and RXSC table so I can trigger failures easily on the ndo_* side. It has exposed a couple of issues. The first patch will cause some performance degradation, but in the current state it's not possible to offload macsec to lower devices that also support ipsec offload. I'm working on re-adding those feature flags when offload is available, but I haven't fully solved that yet. I think it would be safer to do that second part in net-next considering how complex feature interactions tend to be. Sabrina Dubroca (5): Revert "net: macsec: report real_dev features when HW offloading is enabled" macsec: delete new rxsc when offload fails macsec: fix secy->n_rx_sc accounting macsec: fix detection of RXSCs when toggling offloading macsec: clear encryption keys from the stack after setting up offload drivers/net/macsec.c | 51 ++++++++++++++++---------------------------- 1 file changed, 18 insertions(+), 33 deletions(-)