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: [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 ` [PATCH v2 0/2] net/i40e: get information about protocols defined in ddp profile Kirill Rybalchenko
2017-09-01 16:01 ` [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 ` [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 ` [PATCH v3 0/2] net/i40e: " Kirill Rybalchenko
2017-09-19 16:46 ` [PATCH v3 1/2] " Kirill Rybalchenko
2017-09-19 16:46 ` [PATCH v3 2/2] app/testpmd: " Kirill Rybalchenko
2017-09-19 17:32 ` [PATCH v4 0/2] net/i40e: " Kirill Rybalchenko
2017-09-19 17:32 ` [PATCH v4 1/2] " Kirill Rybalchenko
2017-09-19 17:32 ` [PATCH v4 2/2] app/testpmd: " Kirill Rybalchenko
2017-09-19 17:53 ` [PATCH v5 0/2] net/i40e: " Kirill Rybalchenko
2017-09-19 17:53 ` [PATCH v5 1/2] " Kirill Rybalchenko
2017-09-26 3:35 ` Xing, Beilei
2017-09-19 17:53 ` [PATCH v5 2/2] app/testpmd: " Kirill Rybalchenko
2017-09-28 13:33 ` [PATCH v6 0/2] net/i40e: " Kirill Rybalchenko
2017-09-28 13:33 ` [PATCH v6 1/2] " Kirill Rybalchenko
2017-09-29 7:30 ` Xing, Beilei
2017-09-28 13:33 ` [PATCH v6 2/2] app/testpmd: " Kirill Rybalchenko
2017-10-02 9:39 ` [PATCH v7 0/2] net/i40e: " Kirill Rybalchenko
2017-10-02 9:39 ` [PATCH v7 1/2] " Kirill Rybalchenko
2017-10-02 9:39 ` [PATCH v7 2/2] app/testpmd: " Kirill Rybalchenko
2017-10-04 14:00 ` [PATCH v8 0/2] et/i40e: " Kirill Rybalchenko
2017-10-04 14:00 ` [PATCH v8 1/2] net/i40e: " Kirill Rybalchenko
2017-10-04 14:00 ` [PATCH v8 2/2] app/testpmd: " Kirill Rybalchenko
2017-10-04 22:00 ` [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.