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 6C493A0C40; Tue, 8 Jun 2021 14:17:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 30C4940689; Tue, 8 Jun 2021 14:17:29 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 520C34067A for ; Tue, 8 Jun 2021 14:17:27 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id D9C497F502; Tue, 8 Jun 2021 15:17:26 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru D9C497F502 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1623154646; bh=g1hX001bx29gFWRoVQi0EaEG5tuiOGa/dbDyJ29FNo4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=J06M/dWpu+iYOfrPnbZGmaK9lSdXg4LAt0IPO1PBqjVtX1+nsxe3pTHSi0Aj4t3bY TLnVCqRhmKHTByWltafCnGxbgTNpb2bKtGN1mJGC6UsXutlhbS5+Y0iwIoUYh74zUQ T9K4xOzMTgsOc242Xp2hTjSHJkzG0KzuXX2357iQ= To: Raslan Darawsheh , dev@dpdk.org Cc: ferruh.yigit@intel.com, orika@nvidia.com, ivan.malov@oktetlabs.ru, ying.a.wang@intel.com, olivier.matz@6wind.com, viacheslavo@nvidia.com, shirik@nvidia.com References: <20210404074552.24190-1-rasland@nvidia.com> <20210429081048.16627-1-rasland@nvidia.com> <20210429081048.16627-2-rasland@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <06b20c7f-60cf-dbbc-acfb-18f2629476a8@oktetlabs.ru> Date: Tue, 8 Jun 2021 15:17:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210429081048.16627-2-rasland@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5 1/1] ethdev: add new ext hdr for gtp psc 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 Sender: "dev" On 4/29/21 11:10 AM, Raslan Darawsheh wrote: > Define new rte header for gtp PDU session container > based on RFC 38415-g30 > > Signed-off-by: Raslan Darawsheh > --- > lib/net/rte_gtp.h | 78 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 78 insertions(+) > > diff --git a/lib/net/rte_gtp.h b/lib/net/rte_gtp.h > index 6a6f9b238d..5a850a26e4 100644 > --- a/lib/net/rte_gtp.h > +++ b/lib/net/rte_gtp.h > @@ -61,6 +61,84 @@ struct rte_gtp_hdr_ext_word { > uint8_t next_ext; /**< Next Extension Header Type. */ > } __rte_packed; > > +/** > + * Optional extension for GTP with next_ext set to 0x85 > + * defined based on RFC 38415-g30. > + */ > +__extension__ > +struct rte_gtp_psc_generic_hdr { > + uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */ > +#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN > + uint8_t type:4; /**< PDU type */ > + uint8_t qmp:1; /**< Qos Monitoring Packet */ > + uint8_t pad:3; /**< type specfic pad bits */ > + uint8_t spare:2; /**< type specific spare bits */ > + uint8_t qfi:6; /**< Qos Flow Identifier */ > +#else > + uint8_t qfi:6; /**< Qos Flow Identifier */ > + uint8_t spare:2; /**< type specific spare bits */ > + uint8_t pad:3; /**< type specfic pad bits */ > + uint8_t qmp:1; /**< Qos Monitoring Packet */ > + uint8_t type:4; /**< PDU type */ > +#endif > + uint8_t data[0]; /**< variable length data feilds */ > +} __rte_packed; > + > +/** > + * Optional extension for GTP with next_ext set to 0x85 > + * type0 defined based on RFC 38415-g30 > + */ > +__extension__ > +struct rte_gtp_psc_type0_hdr { > + uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */ > +#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN > + uint8_t type:4; /**< PDU type */ > + uint8_t qmp:1; /**< Qos Monitoring Packet */ > + uint8_t snp:1; /**< Sequence number presence */ > + uint8_t spare_dl1:2; /**< spare down link bits */ > + uint8_t ppp:1; /**< Paging policy presence */ > + uint8_t rqi:1; /**< Reflective Qos Indicator */ > + uint8_t qfi:6; /**< Qos Flow Identifier */ > +#else > + uint8_t qfi:6; /**< Qos Flow Identifier */ > + uint8_t rqi:1; /**< Reflective Qos Indicator */ > + uint8_t ppp:1; /**< Paging policy presence */ > + uint8_t spare_dl1:2; /**< spare down link bits */ > + uint8_t snp:1; /**< Sequence number presence */ > + uint8_t type:4; /**< PDU type */ > +#endif > + uint8_t data[0]; /**< variable length data feilds */ > +} __rte_packed; > + > +/** > + * Optional extension for GTP with next_ext set to 0x85 > + * type1 defined based on RFC 38415-g30 > + */ > +__extension__ > +struct rte_gtp_psc_type1_hdr { > + uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */ > +#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN > + uint8_t type:4; /**< PDU type */ > + uint8_t qmp:1; /**< Qos Monitoring Packet */ > + uint8_t dl_delay_ind:1; /**< dl delay result presence */ > + uint8_t ul_delay_ind:1; /**< ul delay result presence */ > + uint8_t snp:1; /**< Sequence number presence ul */ > + uint8_t n_delay_ind:1; /**< N3/N9 delay result presence */ > + uint8_t spare_ul2:1; /**< spare up link bits */ > + uint8_t qfi:6; /**< Qos Flow Identifier */ > +#else > + uint8_t qfi:6; /**< Qos Flow Identifier */ > + uint8_t spare_ul2:1; /**< spare up link bits */ > + uint8_t n_delay_ind:1; /**< N3/N9 delay result presence */ > + uint8_t snp:1; /**< Sequence number presence ul */ > + uint8_t ul_delay_ind:1; /**< ul delay result presence */ > + uint8_t dl_delay_ind:1; /**< dl delay result presence */ > + uint8_t qmp:1; /**< Qos Monitoring Packet */ > + uint8_t type:4; /**< PDU type */ > +#endif > + uint8_t data[0]; /**< variable length data feilds */ > +} __rte_packed; > + > /** GTP header length */ > #define RTE_ETHER_GTP_HLEN \ > (sizeof(struct rte_udp_hdr) + sizeof(struct rte_gtp_hdr)) > This way the structure is very hard to read. May I ask to indent field comments as it is done in other rte_net structures (e.g. rte_ipv4_hdr, rte_udp_hdr, rte_geneve_hdr). Personally I don't care if it will be indent by TABs or spaces, however, it looks like TABs are used in more places.