From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B1689A00C2; Mon, 26 Sep 2022 14:51:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 90A7F4069B; Mon, 26 Sep 2022 14:51:36 +0200 (CEST) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by mails.dpdk.org (Postfix) with ESMTP id 5303E40695 for ; Mon, 26 Sep 2022 14:51:35 +0200 (CEST) Received: by mail-wr1-f42.google.com with SMTP id t7so10025534wrm.10 for ; Mon, 26 Sep 2022 05:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date; bh=ogT+Mkc7cPmhnJIC9wPZi5E+jF/lyg7ejuzQr/nnWgs=; b=HdGoSTmWoi4JL5yqlVUOGKgfS5Iv+IP5lfghI+HC3OLSGRF+fGY4Be+PbqZrM5m5iO +T2xy9pA3c8cRFs8oMkf2D80RcS/pUVf+dn2maAfI9SvQLy2brPbY+iP6MuEUyXK92LP twYEfq271WUAd3sDbssc5J01rjK63wLMeR4BsvKEFp0BySl1trFNWW50gUH2HwA6xfUn medUj5HWMfoLs889O1zzQdlZaeC1eqLevK4ymM//68l675UGWsON36rmu9LKzTOu02Rn H76q6ae9NUHnbNg9glfCnYWDRc7Ik5OgiYhesTsVm3jMWD16QnI4i1fL/Qo6QHbzlZO/ 7a3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=ogT+Mkc7cPmhnJIC9wPZi5E+jF/lyg7ejuzQr/nnWgs=; b=OBuFUGmk6/aR0fyJB1nw6/QlU/3X5pWDt5ivTfh9ciEk2KS1sZGHK2QcLnQfWmerFE zEpMtmDve+QSNIvgTL33lJMOLvYjuj/BPaRZ28f7X0NQwkc2PgdKARfmK+kkOkbDHJb3 o3r48gVmlue26j2ZKGXsGsIz6bHzXXgnZPghI+jXZZhFmKKrgw3Dvl1VpoSwq4sICspf cFXdUmaKfnDuLmZNN3wcnIuEYL2LaUEf7sB5KnK9hedq8u0ZuOHZJOz6b29rTh3OqpMd ddNepxaJYpbKLpF7JfvteiUpFuTpCFjACh9bwhWbWz3hCi5vW9eT9dPdH/9Pec3YjBGC HWCA== X-Gm-Message-State: ACrzQf0Ru4Z9/Rn3uCJj9LA7jPj1ybRJ2GQW3ivgpXRo3JVXfFNAB/22 xBStnIN8h7uGyrCpkUplmdYRkw== X-Google-Smtp-Source: AMsMyM7kZHKSPPSRMtJkBht++XDTyv5FYgIKyQTHY7mOX+Q3mgFHDCw1pzGilhaYdkq+E5/earRoEw== X-Received: by 2002:a05:6000:168e:b0:22a:4e45:7469 with SMTP id y14-20020a056000168e00b0022a4e457469mr12582081wrd.681.1664196694973; Mon, 26 Sep 2022 05:51:34 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id p21-20020a1c5455000000b003b27f644488sm10774348wmi.29.2022.09.26.05.51.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Sep 2022 05:51:33 -0700 (PDT) Date: Mon, 26 Sep 2022 14:51:32 +0200 From: Olivier Matz To: Akhil Goyal Cc: dev@dpdk.org, thomas@monjalon.net, david.marchand@redhat.com, hemant.agrawal@nxp.com, vattunuru@marvell.com, ferruh.yigit@xilinx.com, andrew.rybchenko@oktetlabs.ru, konstantin.v.ananyev@yandex.ru, jiawenwu@trustnetic.com, yisen.zhuang@huawei.com, irusskikh@marvell.com, qiming.yang@intel.com, jerinj@marvell.com, adwivedi@marvell.com Subject: Re: [PATCH 1/3] net: add MACsec header Message-ID: References: <20220814184620.512343-1-gakhil@marvell.com> <20220814184620.512343-2-gakhil@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220814184620.512343-2-gakhil@marvell.com> X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Akhil, Few comments below. On Mon, Aug 15, 2022 at 12:16:18AM +0530, Akhil Goyal wrote: > Added MACsec protocol header to be used for supporting > MACsec protocol offload in hardware or directly in the application. > > Signed-off-by: Akhil Goyal > --- > doc/api/doxy-api-index.md | 3 ++- > lib/net/meson.build | 1 + > lib/net/rte_macsec.h | 56 +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 59 insertions(+), 1 deletion(-) > create mode 100644 lib/net/rte_macsec.h > > diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md > index 186a258be4..99e49340d3 100644 > --- a/doc/api/doxy-api-index.md > +++ b/doc/api/doxy-api-index.md > @@ -126,7 +126,8 @@ The public API headers are grouped by topics: > [Geneve](@ref rte_geneve.h), > [eCPRI](@ref rte_ecpri.h), > [L2TPv2](@ref rte_l2tpv2.h), > - [PPP](@ref rte_ppp.h) > + [PPP](@ref rte_ppp.h), > + [MACsec](@ref rte_macsec.h) > > - **QoS**: > [metering](@ref rte_meter.h), > diff --git a/lib/net/meson.build b/lib/net/meson.build > index e899846578..3e63abaca8 100644 > --- a/lib/net/meson.build > +++ b/lib/net/meson.build > @@ -21,6 +21,7 @@ headers = files( > 'rte_geneve.h', > 'rte_l2tpv2.h', > 'rte_ppp.h', > + 'rte_macsec.h', > ) > > sources = files( > diff --git a/lib/net/rte_macsec.h b/lib/net/rte_macsec.h > new file mode 100644 > index 0000000000..f1b59253f6 > --- /dev/null > +++ b/lib/net/rte_macsec.h > @@ -0,0 +1,56 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(C) 2022 Marvell. > + */ > + > +#ifndef _RTE_MACSEC_H_ > +#define _RTE_MACSEC_H_ > + > +/** > + * @file > + * > + * MACsec-related defines > + */ > + > +#include > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > + > +/* SecTAG length = macsec ether header without the optional SCI */ > +#define RTE_MACSEC_TAG_LEN 6 Use a doxygen-like comment. Is this define required? In my understanding, it is the same as sizeof(struct rte_macsec_hdr). > +#define RTE_MACSEC_SCI_LEN 8 Missing doxygen doc. > + > +#define RTE_MACSEC_TCI_VERSION 0x80 /**< Version mask for MACsec. Should be 0. */ > +#define RTE_MACSEC_TCI_ES 0x40 /**< End station - SCI is not valid */ > +#define RTE_MACSEC_TCI_SC 0x20 /**< SCI present */ > +#define RTE_MACSEC_TCI_SCB 0x10 /**< Secure channel support EPON single copy broadcast */ support -> supports? > +#define RTE_MACSEC_TCI_E 0x08 /**< User data is encrypted */ > +#define RTE_MACSEC_TCI_C 0x04 /**< User data was changed (because of encryption) */ In [1], I can read the following, which is not similar: E and C bits used to determine if packet is encrypted • E, C = 1, 1 – Encrypted • E, C = 0, 0 – Authenticated-Only Is there any reference paper for macsec header? [1] https://www.marvell.com/content/dam/marvell/en/public-collateral/automotive-solutions/marvell-macsec-security-in-ethernet-based-vehicle-white-paper.pdf > +#define RTE_MACSEC_AN_MASK 0x03 /**< Association number mask in tci_an */ nit: all comments should end with a dot. > > +#define RTE_MACSEC_NUM_AN 4 /**< 2 bits for the association number */ I don't get how this defined is used. Can the comment be clarified? > +#define RTE_MACSEC_SALT_LEN 12 /**< Salt length for MACsec SA */ Same here. > + > +/** > + * MACsec Header > + */ > +struct rte_macsec_hdr { > + /* SecTAG */ Is the SecTAG comment required? Or maybe it should be moved above the struct? > + uint8_t tci_an; /**< Tag control information and Association number of SC */ nit: duplicated spaces after uint8_t Can we use a bitfield here for tci and an, like you did for short_length? Like this: uint8_t tci:6; uint8_t an:2; Or: uint8_t tci_version:1; uint8_t tci_es:1; uint8_t tci_sc:1; uint8_t tci_scb:1; uint8_t tci_e:1; uint8_t tci_c:1; uint8_t an:2; I think the 2nd one is easier to use. > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN > + uint8_t short_length : 6; /**< Short Length */ > + uint8_t unused : 2; nit: no spaces around ':' > +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN > + uint8_t unused : 2; > + uint8_t short_length : 6; > +#endif > + rte_be32_t packet_number; /**< Packet number to support replay protection */ > + uint8_t secure_channel_id[8]; /* optional */ 8 -> RTE_MACSEC_SCI_LEN ? I think it would be more convenient to have another struct for the secure_channel_id. For instance, this pseudo code: struct struct rte_macsec_hdr *hdr = NULL; struct struct rte_macsec_sci_hdr *hdr_sci = NULL; if (seg_len(mbuf) < sizeof(*hdr)) return -1; if (hdr.tci_sc) { if (seg_len(mbuf) < sizeof(*hdr_sci)) return -1; hdr_sci = hdr; } With only one struct, it is difficult to properly do the length check. > +} __rte_packed; > + > +#ifdef __cplusplus > +} > +#endif > + > +#endif /* RTE_MACSEC_H_ */ > -- > 2.25.1 > Thanks, Olivier