DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Chengchang Tang <tangchengchang@huawei.com>, dev@dpdk.org
Cc: linuxarm@huawei.com, thomas@monjalon.net,
	arybchenko@solarflare.com, stephen@networkplumber.org
Subject: Re: [dpdk-dev] [PATCH v2] doc: add new field to rxq info struct
Date: Thu, 6 Aug 2020 16:25:06 +0100	[thread overview]
Message-ID: <f71df01a-64c9-a3b3-51b3-bcb8de3586ff@intel.com> (raw)
In-Reply-To: <1596686446-8138-2-git-send-email-tangchengchang@huawei.com>

On 8/6/2020 5:00 AM, Chengchang Tang wrote:
> Struct rte_eth_rxq_info will be modified to include a new field, indicating
> the size of each buffer that could be used for hw to receive packets. Add
> this field to rte_eth_rxq_info to expose relevant information to upper
> layer users/application.
> 
> For more details:
> https://mails.dpdk.org/archives/dev/2020-July/176135.html
> 
> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index ea4cfa7..f08b5f9 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -110,6 +110,15 @@ Deprecation Notices
>    break the ABI checks, that is why change is planned for 20.11.
>    The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``.
>  
> +* ethdev: A new field will be added to the public data structure
> +  ``rte_eth_rxq_info`` to indicate the buffer size used in receiving packets
> +  for HW. When receive packets, HW DMA won't exceed this size.

Overall +1 to provide this information.

This field is only to report back the PMD configured Rx buffer size, it won't
affect the configuration step, do you think should we highlight this?

Also will this field be optional or mandatory, this matters for the scope of the
work for 20.11. I think the intention is to provide an optional field, what do
you think to documenting that it is optional?

> And it will
> +  affect the number of fragments in receiving packets when scatter is enabled.

Is this detail required in the deprecation notice? I see it is relevant but
the configured Rx buffer size affects the number of the fragments, but reporting
this value does not.
Do you want to mention above as motivation to have the field? If so I don't
expect application to calculate the number of the fragments using this value.
I am for dropping above sentences if I am not missing anything.

> +  So, add this field to ``rte_eth_rxq_info`` to expose relevant information to
> +  upper layer user/application.

And not sure above sentences says anything new, looks like duplication to me.

> +  This change is planned for 20.11. For more details:
> +  https://mails.dpdk.org/archives/dev/2020-July/176135.html
> +
>  * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made
>    ABI stable in the v19.11 release. The TM maintainer and other contributors have
>    agreed to keep the TM APIs as experimental in expectation of additional spec
> 


  reply	other threads:[~2020-08-06 15:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05  9:24 [dpdk-dev] [PATCH] " Chengchang Tang
2020-08-05 11:25 ` Andrew Rybchenko
2020-08-06  4:00 ` [dpdk-dev] [PATCH v2] " Chengchang Tang
2020-08-06  4:00   ` Chengchang Tang
2020-08-06 15:25     ` Ferruh Yigit [this message]
2020-08-07  3:51       ` Chengchang Tang
2020-08-07  7:41         ` Thomas Monjalon
2020-08-06 12:50   ` Slava Ovsiienko
2020-08-07  4:00     ` Chengchang Tang
2020-08-07 10:30 ` [dpdk-dev] [PATCH v3] " Chengchang Tang
2020-08-07 10:35   ` Ferruh Yigit
2020-08-07 21:42     ` Thomas Monjalon

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=f71df01a-64c9-a3b3-51b3-bcb8de3586ff@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=linuxarm@huawei.com \
    --cc=stephen@networkplumber.org \
    --cc=tangchengchang@huawei.com \
    --cc=thomas@monjalon.net \
    /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).