All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: Emeel Hakim <ehakim@nvidia.com>,
	davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v2 1/4] vlan: Add MACsec offload operations for VLAN interface
Date: Wed, 29 Mar 2023 21:42:01 +0300	[thread overview]
Message-ID: <20230329184201.GB831478@unreal> (raw)
In-Reply-To: <ZCROr7DhsoRyU1qP@hog>

On Wed, Mar 29, 2023 at 04:43:59PM +0200, Sabrina Dubroca wrote:
> 2023-03-29, 15:21:04 +0300, Emeel Hakim wrote:
> > Add support for MACsec offload operations for VLAN driver
> > to allow offloading MACsec when VLAN's real device supports
> > Macsec offload by forwarding the offload request to it.
> > 
> > Signed-off-by: Emeel Hakim <ehakim@nvidia.com>
> > ---
> > V1 -> V2: - Consult vlan_features when adding NETIF_F_HW_MACSEC.
> 
> Uh? You're not actually doing that? You also dropped the
> changes to vlan_dev_fix_features without explaining why.

vlan_dev_fix_features() relies on real_dev->vlan_features which was set
in mlx5 part of this patch.

  643 static netdev_features_t vlan_dev_fix_features(struct net_device *dev,
  644         netdev_features_t features)
  645 {
  ...
  649
  650         lower_features = netdev_intersect_features((real_dev->vlan_features |
  651                                                     NETIF_F_RXCSUM),
  652                                                    real_dev->features);

This part ensure that once real_dev->vlan_features and real_dev->features have NETIF_F_HW_MACSEC,
the returned features will include NETIF_F_HW_MACSEC too.

> 
> [...]
> > @@ -572,6 +573,9 @@ static int vlan_dev_init(struct net_device *dev)
> >  			   NETIF_F_HIGHDMA | NETIF_F_SCTP_CRC |
> >  			   NETIF_F_ALL_FCOE;
> >  
> > +	if (real_dev->features & NETIF_F_HW_MACSEC)
> > +		dev->hw_features |= NETIF_F_HW_MACSEC;
> > +
> >  	dev->features |= dev->hw_features | NETIF_F_LLTX;
> >  	netif_inherit_tso_max(dev, real_dev);
> >  	if (dev->features & NETIF_F_VLAN_FEATURES)
> > @@ -803,6 +807,100 @@ static int vlan_dev_fill_forward_path(struct net_device_path_ctx *ctx,
> >  	return 0;
> >  }
> >  
> > +#if IS_ENABLED(CONFIG_MACSEC)
> > +
> > +static const struct macsec_ops *vlan_get_macsec_ops(struct macsec_context *ctx)
>                                                        ^ const?
> 
> > +{
> > +	return vlan_dev_priv(ctx->netdev)->real_dev->macsec_ops;
> > +}
> > +
> > +#define _BUILD_VLAN_MACSEC_MDO(mdo) \
> > +	const struct macsec_ops *ops; \
> > +	ops =  vlan_get_macsec_ops(ctx); \
> > +	return ops ? ops->mdo_ ## mdo(ctx) : -EOPNOTSUPP
> > +
> > +static int vlan_macsec_add_txsa(struct macsec_context *ctx)
> > +{
> > +_BUILD_VLAN_MACSEC_MDO(add_txsa);
> 
> Shouldn't those be indented?
> 
> > +}
> > +
> 
> [...]
> > +
> > +#define VLAN_MACSEC_DECLARE_MDO(mdo) .mdo_ ## mdo = vlan_macsec_ ## mdo
> > +
> > +static const struct macsec_ops macsec_offload_ops = {
> > +	VLAN_MACSEC_DECLARE_MDO(add_txsa),
> 
> This completely breaks the ability to use cscope when looking for
> implementations of mdo_add_txsa. I'm not very fond of the c/p, but I
> don't think we should be using macros at all here. At least to me,
> being able to navigate directly from mdo_add_txsa to its
> implementation without expanding the macro manually is important.
> 
> So, IMHO, those should be:
> 
> 	.mdo_add_txsa = vlan_macsec_add_txsa,

Completely agree with you.

> 
> (etc)
> 
> -- 
> Sabrina
> 

  reply	other threads:[~2023-03-29 18:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29 12:21 [PATCH net-next v2 0/4] Support MACsec VLAN Emeel Hakim
2023-03-29 12:21 ` [PATCH net-next v2 1/4] vlan: Add MACsec offload operations for VLAN interface Emeel Hakim
2023-03-29 14:43   ` Sabrina Dubroca
2023-03-29 18:42     ` Leon Romanovsky [this message]
2023-03-30 17:19       ` Sabrina Dubroca
2023-03-30 17:42         ` Jakub Kicinski
2023-03-31 14:33           ` Emeel Hakim
2023-03-30 18:56         ` Leon Romanovsky
2023-03-30 20:32           ` Sabrina Dubroca
2023-04-03  9:29             ` Emeel Hakim
2023-04-04 12:53               ` Sabrina Dubroca
2023-04-04 14:37                 ` Emeel Hakim
2023-04-05  9:35                   ` Sabrina Dubroca
2023-04-05  9:27   ` Sabrina Dubroca
2023-04-05  9:36     ` Emeel Hakim
2023-03-29 12:21 ` [PATCH net-next 2/4] net/mlx5: Support MACsec over VLAN Emeel Hakim
2023-03-29 12:21 ` [PATCH net-next 3/4] net/mlx5: Consider VLAN interface in MACsec TX steering rules Emeel Hakim
2023-03-29 12:21 ` [PATCH net-next 4/4] macsec: Add MACsec rx_handler change support Emeel Hakim
2023-04-05  9:35   ` Sabrina Dubroca
2023-04-05  9:41     ` Emeel Hakim
2023-03-29 18:37 ` [PATCH net-next v2 0/4] Support MACsec VLAN Leon Romanovsky

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=20230329184201.GB831478@unreal \
    --to=leon@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ehakim@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --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.