From: Akhil Goyal <akhil.goyal@nxp.com>
To: Bing Zhao <bingz@mellanox.com>,
"orika@mellanox.com" <orika@mellanox.com>,
"john.mcnamara@intel.com" <john.mcnamara@intel.com>,
"marko.kovacevic@intel.com" <marko.kovacevic@intel.com>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
"olivier.matz@6wind.com" <olivier.matz@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"wenzhuo.lu@intel.com" <wenzhuo.lu@intel.com>,
"beilei.xing@intel.com" <beilei.xing@intel.com>,
"bernard.iremonger@intel.com" <bernard.iremonger@intel.com>
Subject: Re: [dpdk-dev] [PATCH v4 1/2] rte_flow: add eCPRI key fields to flow API
Date: Wed, 8 Jul 2020 18:49:33 +0000 [thread overview]
Message-ID: <VI1PR04MB31685770B9E68ED28DA281FBE6670@VI1PR04MB3168.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <1594136219-133336-2-git-send-email-bingz@mellanox.com>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * eCPRI Protocol Revision 1.0, 1.1, 1.2, 2.0: 0001b
> + * Other values are reserved for future
> + */
> +#define RTE_ECPRI_REV_UPTO_20 1
> +
> +/**
> + * eCPRI message types in specifications
> + * IWF* types will only be supported from rev.2
> + */
> +#define RTE_ECPRI_MSG_TYPE_IQ_DATA 0
> +#define RTE_ECPRI_MSG_TYPE_BIT_SEQ 1
> +#define RTE_ECPRI_MSG_TYPE_RTC_CTRL 2
> +#define RTE_ECPRI_MSG_TYPE_GEN_DATA 3
> +#define RTE_ECPRI_MSG_TYPE_RM_ACC 4
> +#define RTE_ECPRI_MSG_TYPE_DLY_MSR 5
> +#define RTE_ECPRI_MSG_TYPE_RMT_RST 6
> +#define RTE_ECPRI_MSG_TYPE_EVT_IND 7
> +#define RTE_ECPRI_MSG_TYPE_IWF_UP 8
> +#define RTE_ECPRI_MSG_TYPE_IWF_OPT 9
> +#define RTE_ECPRI_MSG_TYPE_IWF_MAP 10
> +#define RTE_ECPRI_MSG_TYPE_IWF_DCTRL 11
Should we have a comment for reserved and vendor specific message types as well?
> +
> +/**
> + * eCPRI Common Header
> + */
> +RTE_STD_C11
> +struct rte_ecpri_common_hdr {
> +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> + uint32_t size:16; /**< Payload Size */
> + uint32_t type:8; /**< Message Type */
> + uint32_t c:1; /**< Concatenation Indicator */
> + uint32_t res:3; /**< Reserved */
> + uint32_t revision:4; /**< Protocol Revision */
> +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
> + uint32_t revision:4; /**< Protocol Revision */
> + uint32_t res:3; /**< Reserved */
> + uint32_t c:1; /**< Concatenation Indicator */
> + uint32_t type:8; /**< Message Type */
> + uint32_t size:16; /**< Payload Size */
> +#endif
> +} __rte_packed;
> +
> +/**
> + * eCPRI Message Header of Type #0: IQ Data
> + */
> +struct rte_ecpri_msg_iq_data {
> + rte_be16_t pc_id; /**< Physical channel ID */
> + rte_be16_t seq_id; /**< Sequence ID */
> +};
> +
> +/**
> + * eCPRI Message Header of Type #1: Bit Sequence
> + */
> +struct rte_ecpri_msg_bit_seq {
> + rte_be16_t pc_id; /**< Physical channel ID */
> + rte_be16_t seq_id; /**< Sequence ID */
> +};
> +
> +/**
> + * eCPRI Message Header of Type #2: Real-Time Control Data
> + */
> +struct rte_ecpri_msg_rtc_ctrl {
> + rte_be16_t rtc_id; /**< Real-Time Control Data ID */
> + rte_be16_t seq_id; /**< Sequence ID */
> +};
> +
> +/**
> + * eCPRI Message Header of Type #3: Generic Data Transfer
> + */
> +struct rte_ecpri_msg_gen_data {
> + rte_be32_t pc_id; /**< Physical channel ID */
> + rte_be32_t seq_id; /**< Sequence ID */
> +};
> +
> +/**
> + * eCPRI Message Header of Type #4: Remote Memory Access
> + */
> +RTE_STD_C11
> +struct rte_ecpri_msg_rm_access {
> +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> + uint32_t ele_id:16; /**< Element ID */
> + uint32_t rr:4; /**< Req/Resp */
> + uint32_t rw:4; /**< Read/Write */
> + uint32_t rma_id:8; /**< Remote Memory Access ID */
> +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
> + uint32_t rma_id:8; /**< Remote Memory Access ID */
> + uint32_t rw:4; /**< Read/Write */
> + uint32_t rr:4; /**< Req/Resp */
> + uint32_t ele_id:16; /**< Element ID */
> +#endif
> + rte_be16_t addr_m; /**< 48-bits address (16 MSB) */
> + rte_be32_t addr_l; /**< 48-bits address (32 LSB) */
> + rte_be16_t length; /**< number of bytes */
> +} __rte_packed;
> +
> +/**
> + * eCPRI Message Header of Type #5: One-Way Delay Measurement
> + */
> +struct rte_ecpri_msg_delay_measure {
> + uint8_t msr_id; /**< Measurement ID */
> + uint8_t act_type; /**< Action Type */
Should we also add timestamp and compensation fields as well here?
> +};
> +
> +/**
> + * eCPRI Message Header of Type #6: Remote Reset
> + */
> +struct rte_ecpri_msg_remote_reset {
> + uint8_t msr_id; /**< Measurement ID */
> + uint8_t act_type; /**< Action Type */
> +};
I think it is a copy paste error.
It should have uint16_t reset_id and uint8_t reset_code_op
> +
> +/**
> + * eCPRI Message Header of Type #7: Event Indication
> + */
> +struct rte_ecpri_msg_event_ind {
> + uint8_t evt_id; /**< Event ID */
> + uint8_t evt_type; /**< Event Type */
> + uint8_t seq; /**< Sequence Number */
> + uint8_t number; /**< Number of Faults/Notif */
> +};
Should we also define enums for evt_type and other fields in this file.
> +
> +/**
> + * eCPRI Message Header Format: Common Header + Message Types
> + */
> +RTE_STD_C11
> +struct rte_ecpri_msg_hdr {
> + union {
> + struct rte_ecpri_common_hdr common;
> + uint32_t dw0;
> + };
> + union {
> + struct rte_ecpri_msg_iq_data type0;
> + struct rte_ecpri_msg_bit_seq type1;
> + struct rte_ecpri_msg_rtc_ctrl type2;
> + struct rte_ecpri_msg_bit_seq type3;
> + struct rte_ecpri_msg_rm_access type4;
> + struct rte_ecpri_msg_delay_measure type5;
> + struct rte_ecpri_msg_remote_reset type6;
> + struct rte_ecpri_msg_event_ind type7;
> + uint32_t dummy[3];
Why 3 dummy? IWF messages are 4.
> + };
> +};
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* _RTE_ECPRI_H_ */
> diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
> index 0ae4e75..184a3f9 100644
> --- a/lib/librte_net/rte_ether.h
> +++ b/lib/librte_net/rte_ether.h
> @@ -304,6 +304,7 @@ struct rte_vlan_hdr {
> #define RTE_ETHER_TYPE_LLDP 0x88CC /**< LLDP Protocol. */
> #define RTE_ETHER_TYPE_MPLS 0x8847 /**< MPLS ethertype. */
> #define RTE_ETHER_TYPE_MPLSM 0x8848 /**< MPLS multicast ethertype. */
> +#define RTE_ETHER_TYPE_ECPRI 0xAEFE /**< eCPRI ethertype (.1Q supported).
> */
>
> /**
> * Extract VLAN tag information into mbuf
> --
> 1.8.3.1
next prev parent reply other threads:[~2020-07-08 18:49 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-28 16:20 [dpdk-dev] [PATCH] " Bing Zhao
2020-07-02 6:46 ` [dpdk-dev] [PATCH v2] " Bing Zhao
2020-07-02 8:06 ` Ori Kam
2020-07-02 12:53 ` [dpdk-dev] [PATCH v3 0/2] rte_flow: introduce eCPRI item for rte_flow Bing Zhao
2020-07-02 12:53 ` [dpdk-dev] [PATCH v3 1/2] rte_flow: add eCPRI key fields to flow API Bing Zhao
2020-07-05 11:34 ` Ori Kam
2020-07-02 12:53 ` [dpdk-dev] [PATCH v3 2/2] app/testpmd: add eCPRI in flow creation patterns Bing Zhao
2020-07-05 11:36 ` Ori Kam
2020-07-07 15:36 ` [dpdk-dev] [PATCH v4 0/2] rte_flow: introduce eCPRI item for rte_flow Bing Zhao
2020-07-07 15:36 ` [dpdk-dev] [PATCH v4 1/2] rte_flow: add eCPRI key fields to flow API Bing Zhao
2020-07-08 18:49 ` Akhil Goyal [this message]
2020-07-09 3:58 ` Bing Zhao
2020-07-07 15:36 ` [dpdk-dev] [PATCH v4 2/2] app/testpmd: add eCPRI in flow creation patterns Bing Zhao
2020-07-10 8:45 ` [dpdk-dev] [PATCH v5 0/2] rte_flow: introduce eCPRI item for rte_flow Bing Zhao
2020-07-10 8:45 ` [dpdk-dev] [PATCH v5 1/2] rte_flow: add eCPRI key fields to flow API Bing Zhao
2020-07-10 14:31 ` Olivier Matz
2020-07-11 4:25 ` Bing Zhao
2020-07-12 13:17 ` Olivier Matz
2020-07-12 14:28 ` Bing Zhao
2020-07-12 14:43 ` Olivier Matz
2020-07-10 8:45 ` [dpdk-dev] [PATCH v5 2/2] app/testpmd: add eCPRI in flow creation patterns Bing Zhao
2020-07-12 13:35 ` [dpdk-dev] [PATCH v6 0/2] rte_flow: introduce eCPRI item for rte_flow Bing Zhao
2020-07-12 13:35 ` [dpdk-dev] [PATCH v6 1/2] rte_flow: add eCPRI key fields to flow API Bing Zhao
2020-07-12 14:45 ` Olivier Matz
2020-07-12 14:50 ` Bing Zhao
2020-07-13 0:50 ` Thomas Monjalon
2020-07-13 8:30 ` Ferruh Yigit
2020-07-12 13:35 ` [dpdk-dev] [PATCH v6 2/2] app/testpmd: add eCPRI in flow creation patterns Bing Zhao
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=VI1PR04MB31685770B9E68ED28DA281FBE6670@VI1PR04MB3168.eurprd04.prod.outlook.com \
--to=akhil.goyal@nxp.com \
--cc=arybchenko@solarflare.com \
--cc=beilei.xing@intel.com \
--cc=bernard.iremonger@intel.com \
--cc=bingz@mellanox.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=john.mcnamara@intel.com \
--cc=marko.kovacevic@intel.com \
--cc=olivier.matz@6wind.com \
--cc=orika@mellanox.com \
--cc=thomas@monjalon.net \
--cc=wenzhuo.lu@intel.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).