From: Sabrina Dubroca <sd@queasysnail.net>
To: "Radu Pirea (OSS)" <radu-nicolae.pirea@oss.nxp.com>
Cc: andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, richardcochran@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC net-next v1 4/5] net: macsec: introduce mdo_insert_tx_tag
Date: Thu, 17 Aug 2023 12:31:23 +0200 [thread overview]
Message-ID: <ZN32-0fwIMtrc9lu@hog> (raw)
In-Reply-To: <c28591b1-812f-b593-ef83-72e972d5b7bd@oss.nxp.com>
2023-08-17, 11:25:36 +0300, Radu Pirea (OSS) wrote:
>
>
> On 16.08.2023 23:40, Sabrina Dubroca wrote:
> > 2023-08-11, 18:32:48 +0300, Radu Pirea (NXP OSS) wrote:
> > > Offloading MACsec in PHYs requires inserting the SecTAG and the ICV in
> > > the ethernet frame. This operation will increase the frame size with 32
> > > bytes.
> >
> > "up to 32 bytes"?
>
> Yes, up to 32 bytes.
>
> >
> > The SecTAG and ICV can both be shorter, at least with the software
> > implementation.
> >
> >
> > [...]
> > > +static struct sk_buff *insert_tx_tag(struct sk_buff *skb,
> > > + struct net_device *dev)
> > > +{
> > [...]
> > > +
> > > + ctx.secy = &macsec->secy;
> > > + ctx.skb = skb;
> >
> > I think it would be a bit more readable to just pass the skb to
> > ->mdo_insert_tx_tag instead of adding it to the context.
>
> Since this function requires only the skb and the phydev, I would move
> mdo_insert_tx_tag from macsec_ops to a new structure called mascec_tag. What
> do you think about this?
I think it's ok to leave it in macsec_ops.
[...]
> > > @@ -4137,6 +4211,11 @@ static int macsec_newlink(struct net *net, struct net_device *dev,
> > > if (err)
> > > goto del_dev;
> > > }
> > > +
> > > + dev->needed_headroom -= MACSEC_NEEDED_HEADROOM;
> > > + dev->needed_headroom += ops->needed_headroom;
> > > + dev->needed_tailroom -= MACSEC_NEEDED_TAILROOM;
> > > + dev->needed_tailroom += ops->needed_tailroom;
> >
> > If the driver doesn't set ops->needed_headroom, we'll subtract
> > MACSEC_NEEDED_HEADROOM and not add anything back. Is that correct for
> > all existing drivers? (and same for tailroom)
>
> It should be. However, I will do this operation only for the PHYs that needs
> to parse a tag.
>
> >
> > You set needed_tailroom to 0 in your driver, but the commit message
> > for this patch says that the HW needs space for the ICV. I'm a bit
> > puzzled by this, especially since MACSEC_NEEDED_TAILROOM already
> > reserves space for the ICV.
>
> The 32 bytes headroom will compensate for 0 bytes tailroom.
Ok.
One more question about the ordering of patches in this series: is
macsec offload with your device functional without this and the final
patch? Otherwise, I would put this patch first, and then the driver
patches (either collapsed into a single patch, or preferably split out
if there's a reasonable way to do it -- patch 3 is really huge and
hard to review).
--
Sabrina
next prev parent reply other threads:[~2023-08-17 10:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-11 15:32 [RFC net-next v1 0/5] Add MACsec support for TJA11XX C45 PHYs Radu Pirea (NXP OSS)
2023-08-11 15:32 ` [RFC net-next v1 1/5] net: macsec: declare macsec_pn_wrapped shim Radu Pirea (NXP OSS)
2023-08-11 15:32 ` [RFC net-next v1 2/5] net: phy: remove MACSEC guard Radu Pirea (NXP OSS)
2023-08-11 16:59 ` Andrew Lunn
2023-08-14 15:35 ` Sabrina Dubroca
2023-08-14 15:50 ` Andrew Lunn
2023-08-11 15:32 ` [RFC net-next v1 3/5] net: phy: nxp-c45-tja11xx add MACsec support Radu Pirea (NXP OSS)
2023-08-11 17:10 ` Andrew Lunn
2023-08-16 8:18 ` Radu Pirea (OSS)
2023-08-12 18:01 ` Simon Horman
2023-08-11 15:32 ` [RFC net-next v1 4/5] net: macsec: introduce mdo_insert_tx_tag Radu Pirea (NXP OSS)
2023-08-11 17:42 ` Andrew Lunn
2023-08-16 10:12 ` Radu Pirea (OSS)
2023-08-12 18:07 ` Simon Horman
2023-08-16 10:19 ` Radu Pirea (OSS)
2023-08-16 20:40 ` Sabrina Dubroca
2023-08-17 8:25 ` Radu Pirea (OSS)
2023-08-17 10:31 ` Sabrina Dubroca [this message]
2023-08-17 11:19 ` Radu Pirea (OSS)
2023-08-11 15:32 ` [RFC net-next v1 5/5] net: phy: nxp-c45-tja11xx: implement mdo_insert_tx_tag Radu Pirea (NXP OSS)
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=ZN32-0fwIMtrc9lu@hog \
--to=sd@queasysnail.net \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=radu-nicolae.pirea@oss.nxp.com \
--cc=richardcochran@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).