All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Antoine Tenart <atenart@kernel.org>
Cc: Sabrina Dubroca <sd@queasysnail.net>,
	netdev@vger.kernel.org,
	Mark Starovoytov <mstarovoitov@marvell.com>,
	Igor Russkikh <irusskikh@marvell.com>
Subject: Re: [PATCH net 0/5] macsec: offload-related fixes
Date: Tue, 18 Oct 2022 09:28:08 +0300	[thread overview]
Message-ID: <Y05HeGnTKBY0RVI4@unreal> (raw)
In-Reply-To: <166575623691.3451.2587099917911763555@kwain>

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

  reply	other threads:[~2022-10-18  6:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-13 14:15 [PATCH net 0/5] macsec: offload-related fixes Sabrina Dubroca
2022-10-13 14:15 ` [PATCH net 1/5] Revert "net: macsec: report real_dev features when HW offloading is enabled" Sabrina Dubroca
2022-10-13 14:15 ` [PATCH net 2/5] macsec: delete new rxsc when offload fails Sabrina Dubroca
2022-10-13 14:15 ` [PATCH net 3/5] macsec: fix secy->n_rx_sc accounting Sabrina Dubroca
2022-10-14  6:16   ` Leon Romanovsky
2022-10-14  7:43     ` Sabrina Dubroca
2022-10-14 11:08       ` Leon Romanovsky
2022-10-13 14:15 ` [PATCH net 4/5] macsec: fix detection of RXSCs when toggling offloading Sabrina Dubroca
2022-10-13 14:15 ` [PATCH net 5/5] macsec: clear encryption keys from the stack after setting up offload Sabrina Dubroca
2022-10-14  6:13 ` [PATCH net 0/5] macsec: offload-related fixes Leon Romanovsky
2022-10-14  7:43   ` Sabrina Dubroca
2022-10-14 11:03     ` Leon Romanovsky
2022-10-14 14:03       ` Antoine Tenart
2022-10-18  6:28         ` Leon Romanovsky [this message]
2022-10-20 13:54           ` Sabrina Dubroca
2022-10-23  7:52             ` Leon Romanovsky
2022-10-24  8:24               ` Sabrina Dubroca
2022-10-24  8:43                 ` Leon Romanovsky
2022-10-24 22:05                   ` Sabrina Dubroca
2022-10-25  6:55                     ` Leon Romanovsky
2022-10-14 14:44       ` Sabrina Dubroca

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y05HeGnTKBY0RVI4@unreal \
    --to=leon@kernel.org \
    --cc=atenart@kernel.org \
    --cc=irusskikh@marvell.com \
    --cc=mstarovoitov@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=sd@queasysnail.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.