[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c28591b1-812f-b593-ef83-72e972d5b7bd@oss.nxp.com>
Date: Thu, 17 Aug 2023 11:25:36 +0300
From: "Radu Pirea (OSS)" <radu-nicolae.pirea@....nxp.com>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: andrew@...n.ch, hkallweit1@...il.com, linux@...linux.org.uk,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, richardcochran@...il.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC net-next v1 4/5] net: macsec: introduce mdo_insert_tx_tag
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?
>
>> +
>> + err = ops->mdo_insert_tx_tag(&ctx);
>> + if (err)
>> + goto cleanup;
>
> [...]
>> @@ -3403,6 +3470,13 @@ static netdev_tx_t macsec_start_xmit(struct sk_buff *skb,
>> skb_dst_drop(skb);
>> dst_hold(&md_dst->dst);
>> skb_dst_set(skb, &md_dst->dst);
>> +
>> + skb = insert_tx_tag(skb, dev);
>> + if (IS_ERR(skb)) {
>> + dev->stats.tx_dropped++;
>
> That should probably use DEV_STATS_INC (see commit
> 32d0a49d36a2 ("macsec: use DEV_STATS_INC()")).
>
>> + return NETDEV_TX_OK;
>> + }
>> +
>> skb->dev = macsec->real_dev;
>> return dev_queue_xmit(skb);
>> }
>> @@ -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.
>
> Also, since this is pattern repeated twice more (with a sign change)
> in macsec_update_offload, we could probably stuff this into a helper
> (either modifying dev->needed_headroom directly, or returning the
> value to add/subtract).
Agreed.
>
>> }
>>
>
> [...]
>> @@ -302,6 +303,10 @@ struct macsec_ops {
>> int (*mdo_get_tx_sa_stats)(struct macsec_context *ctx);
>> int (*mdo_get_rx_sc_stats)(struct macsec_context *ctx);
>> int (*mdo_get_rx_sa_stats)(struct macsec_context *ctx);
>> + /* Offload tag */
>> + int (*mdo_insert_tx_tag)(struct macsec_context *ctx);
>> + int needed_headroom;
>> + int needed_tailroom;
>
> unsigned?
OK.
>
>> };
>
--
Radu P.
Powered by blists - more mailing lists