From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Kirill Rybalchenko <kirill.rybalchenko@intel.com>, dev@dpdk.org
Cc: andrey.chilikin@intel.com, beilei.xing@intel.com, jingjing.wu@intel.com
Subject: Re: [dpdk-dev] [PATCH v2 1/2] net/i40e: get information about protocols defined in ddp profile
Date: Mon, 11 Sep 2017 16:32:15 +0100 [thread overview]
Message-ID: <53af3906-009a-474c-e191-3f8dc52b080a@intel.com> (raw)
In-Reply-To: <1504281685-54502-2-git-send-email-kirill.rybalchenko@intel.com>
On 9/1/2017 5:01 PM, Kirill Rybalchenko wrote:
> This patch adds new package info types to get list of protocols,
> pctypes and ptypes defined in a profile
>
> Signed-off-by: Kirill Rybalchenko <kirill.rybalchenko@intel.com>
<...>
> +/* Get number of tvl records in the section */
> +static unsigned
> +i40e_get_tlv_section_size(struct i40e_profile_section_header *sec)
> +{
> + unsigned int i, nb_rec, nb_tlv = 0;
> + struct i40e_profile_tlv_section_record *tlv;
> +
> + if (!sec)
> + return nb_tlv;
> +
> + /* get number of records in the section */
> + nb_rec = sec->section.size / sizeof(struct i40e_profile_tlv_section_record);
> + for (i = 0; i < nb_rec; ) {
> + tlv = (struct i40e_profile_tlv_section_record *)&sec[1 + i];
> + i += tlv->len;
"sec[1 + i]" cast to tlv struct, and "i" increased by tlv->len, can you
please confirm tlv->len is measure of tlv_section_record, not bytes.
> + nb_tlv++;
> + }
> + return nb_tlv;
> +}
<...>
> + /* get list of protocols */
> + if (type == RTE_PMD_I40E_PKG_INFO_PROTOCOL_LIST) {
> + uint32_t i, j, nb_rec;
> + struct rte_pmd_i40e_proto_info *pinfo;
> + struct i40e_profile_section_header *proto;
> + struct i40e_profile_tlv_section_record *tlv;
> +
> + proto = i40e_find_section_in_profile(SECTION_TYPE_PROTO,
> + (struct i40e_profile_segment *)i40e_seg_hdr);
> + nb_rec = i40e_get_tlv_section_size(proto);
> + if (info_size < nb_rec) {
Is there an assumption that for this type, info_size is measure of
records instead of input buffer size in bytes as other types? I believe
info_size should be consistent between types.
<...>
> + /* get list of packet classification types */
> + if (type == RTE_PMD_I40E_PKG_INFO_PCTYPE_LIST) {
> + uint32_t i, j, nb_rec;
> +
> + struct rte_pmd_i40e_ptype_info *pinfo;> + struct i40e_profile_section_header *pctype;
> + struct i40e_profile_tlv_section_record *tlv;
> +
> + pctype = i40e_find_section_in_profile(SECTION_TYPE_PCTYPE,
> + (struct i40e_profile_segment *)i40e_seg_hdr);
> + nb_rec = i40e_get_tlv_section_size(pctype);
> + if (info_size < nb_rec) {
Same as above, info_size assumed to number of structs, not size in bytes.
> + PMD_DRV_LOG(ERR, "Invalid information buffer size");
> + return -EINVAL;
> + }
> + pinfo = (struct rte_pmd_i40e_ptype_info *)info_buff;
Just to double check, both types PCTYPE_LIST and PTYPE_LIST types are
returning "rte_pmd_i40e_ptype_info"? So no specific struct for pctype?
> + for (i = 0; i < info_size; i++)
> + memset(&pinfo[i], RTE_PMD_I40E_PROTO_UNUSED,
> + sizeof(struct rte_pmd_i40e_ptype_info));
> +
> + if (nb_rec == 0)
> + return I40E_SUCCESS;
> + /* get number of records in the section */
> + nb_rec = pctype->section.size /
> + sizeof(struct i40e_profile_tlv_section_record);
> + tlv = (struct i40e_profile_tlv_section_record *)&pctype[1];
> + for (i = j = 0; i < nb_rec; j++) {
> + pinfo[j].ptype_id = tlv->data[0];
> + memcpy(&pinfo[j], tlv->data,
> + sizeof(struct rte_pmd_i40e_ptype_info));
This overwrites one line above, intentional?
<...>
> + /* get list of packet types */
> + if (type == RTE_PMD_I40E_PKG_INFO_PTYPE_LIST) {
> + uint32_t i, nb_rec;
> + struct rte_pmd_i40e_ptype_info *pinfo;
> + struct i40e_profile_section_header *ptype;
> + struct i40e_profile_tlv_section_record *tlv;
> +
> + ptype = i40e_find_section_in_profile(SECTION_TYPE_PTYPE,
> + (struct i40e_profile_segment *)i40e_seg_hdr);
> + nb_rec = i40e_get_tlv_section_size(ptype);
> + if (info_size < nb_rec) {
Same as above.
> + PMD_DRV_LOG(ERR, "Invalid information buffer size");
> + return -EINVAL;
> + }
> + pinfo = (struct rte_pmd_i40e_ptype_info *)info_buff;
> + for (i = 0; i < info_size; i++)
> + memset(&pinfo[i], RTE_PMD_I40E_PROTO_UNUSED,
> + sizeof(struct rte_pmd_i40e_ptype_info));
> +
> + if (nb_rec == 0)
> + return I40E_SUCCESS;
> + /* get number of records in the section */
> + nb_rec = ptype->section.size /
> + sizeof(struct i40e_profile_tlv_section_record);
> + for (i = 0; i < nb_rec; ) {
> + tlv = (struct i40e_profile_tlv_section_record *)&ptype[1 + i];
> + pinfo[i].ptype_id = tlv->data[0];
> + memcpy(&pinfo[i], tlv->data,
> + sizeof(struct rte_pmd_i40e_ptype_info));
same as above.
<...>
> --- a/drivers/net/i40e/rte_pmd_i40e.h
> +++ b/drivers/net/i40e/rte_pmd_i40e.h
> @@ -88,6 +88,12 @@ enum rte_pmd_i40e_package_info {
> RTE_PMD_I40E_PKG_INFO_HEADER,
> RTE_PMD_I40E_PKG_INFO_DEVID_NUM,
> RTE_PMD_I40E_PKG_INFO_DEVID_LIST,
> + RTE_PMD_I40E_PKG_INFO_PROTOCOL_NUM,
> + RTE_PMD_I40E_PKG_INFO_PROTOCOL_LIST,
> + RTE_PMD_I40E_PKG_INFO_PCTYPE_NUM,
> + RTE_PMD_I40E_PKG_INFO_PCTYPE_LIST,
> + RTE_PMD_I40E_PKG_INFO_PTYPE_NUM,
> + RTE_PMD_I40E_PKG_INFO_PTYPE_LIST,
> RTE_PMD_I40E_PKG_INFO_MAX = 0xFFFFFFFF
This is not part of this patch, but out of curiosity, what is the use
case of defining a max in enum with a fixed number?
> };
>
> @@ -133,6 +139,25 @@ struct rte_pmd_i40e_profile_list {
> struct rte_pmd_i40e_profile_info p_info[1];
> };
>
> +#define RTE_PMD_I40E_PROTO_NUM 6
> +#define RTE_PMD_I40E_PROTO_UNUSED 0xFF
> +
> +/**
> +* Protocols information stored in profile
> +*/
> +struct rte_pmd_i40e_proto_info {
> + uint8_t proto_id;
> + char name[RTE_PMD_I40E_DDP_NAME_SIZE];
> +};
> +
> +/**
> +* Packet classification/ packet type information stored in profile
> +*/
> +struct rte_pmd_i40e_ptype_info {
> + uint8_t ptype_id;
> + uint8_t protocols[RTE_PMD_I40E_PROTO_NUM];
> +};
> +
> /**
> * ptype mapping table only accept RTE_PTYPE_XXX or "user defined" ptype.
> * A ptype with MSB set will be regarded as a user defined ptype.
>
next prev parent reply other threads:[~2017-09-11 15:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4075836-102681-1-git-send-email-kirill.rybalchenko@intel.com>
2017-09-01 16:01 ` [dpdk-dev] [PATCH v2 0/2] " Kirill Rybalchenko
2017-09-01 16:01 ` [dpdk-dev] [PATCH v2 1/2] " Kirill Rybalchenko
2017-09-04 12:36 ` Iremonger, Bernard
2017-09-11 15:32 ` Ferruh Yigit [this message]
2017-09-01 16:01 ` [dpdk-dev] [PATCH v2 2/2] app/testpmd: " Kirill Rybalchenko
2017-09-04 12:44 ` Iremonger, Bernard
2017-09-04 12:46 ` Iremonger, Bernard
2017-09-11 15:32 ` Ferruh Yigit
2017-09-19 16:46 ` [dpdk-dev] [PATCH v3 0/2] net/i40e: " Kirill Rybalchenko
2017-09-19 16:46 ` [dpdk-dev] [PATCH v3 1/2] " Kirill Rybalchenko
2017-09-19 16:46 ` [dpdk-dev] [PATCH v3 2/2] app/testpmd: " Kirill Rybalchenko
2017-09-19 17:32 ` [dpdk-dev] [PATCH v4 0/2] net/i40e: " Kirill Rybalchenko
2017-09-19 17:32 ` [dpdk-dev] [PATCH v4 1/2] " Kirill Rybalchenko
2017-09-19 17:32 ` [dpdk-dev] [PATCH v4 2/2] app/testpmd: " Kirill Rybalchenko
2017-09-19 17:53 ` [dpdk-dev] [PATCH v5 0/2] net/i40e: " Kirill Rybalchenko
2017-09-19 17:53 ` [dpdk-dev] [PATCH v5 1/2] " Kirill Rybalchenko
2017-09-26 3:35 ` Xing, Beilei
2017-09-19 17:53 ` [dpdk-dev] [PATCH v5 2/2] app/testpmd: " Kirill Rybalchenko
2017-09-28 13:33 ` [dpdk-dev] [PATCH v6 0/2] net/i40e: " Kirill Rybalchenko
2017-09-28 13:33 ` [dpdk-dev] [PATCH v6 1/2] " Kirill Rybalchenko
2017-09-29 7:30 ` Xing, Beilei
2017-09-28 13:33 ` [dpdk-dev] [PATCH v6 2/2] app/testpmd: " Kirill Rybalchenko
2017-10-02 9:39 ` [dpdk-dev] [PATCH v7 0/2] net/i40e: " Kirill Rybalchenko
2017-10-02 9:39 ` [dpdk-dev] [PATCH v7 1/2] " Kirill Rybalchenko
2017-10-02 9:39 ` [dpdk-dev] [PATCH v7 2/2] app/testpmd: " Kirill Rybalchenko
2017-10-04 14:00 ` [dpdk-dev] [PATCH v8 0/2] et/i40e: " Kirill Rybalchenko
2017-10-04 14:00 ` [dpdk-dev] [PATCH v8 1/2] net/i40e: " Kirill Rybalchenko
2017-10-04 14:00 ` [dpdk-dev] [PATCH v8 2/2] app/testpmd: " Kirill Rybalchenko
2017-10-04 22:00 ` [dpdk-dev] [PATCH v8 0/2] et/i40e: " Ferruh Yigit
2017-10-05 1:11 ` Ferruh Yigit
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=53af3906-009a-474c-e191-3f8dc52b080a@intel.com \
--to=ferruh.yigit@intel.com \
--cc=andrey.chilikin@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@intel.com \
--cc=kirill.rybalchenko@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).