DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Varghese, Vipin" <vipin.varghese@intel.com>
To: Shreyansh Jain <shreyansh.jain@nxp.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"Kovacevic, Marko" <marko.kovacevic@intel.com>,
	"honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>,
	"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	"Mcnamara, John" <john.mcnamara@intel.com>,
	"Patel, Amol" <amol.patel@intel.com>
Subject: Re: [dpdk-dev] [PATCH v3 2/2] doc: add guide for debug and troubleshoot
Date: Fri, 4 Jan 2019 07:01:58 +0000	[thread overview]
Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2E06C1@BGSMSX101.gar.corp.intel.com> (raw)
In-Reply-To: <fb5f6a00-e383-1362-72d0-9e2b32898b52@nxp.com>

Hi Shreyansh jain,

Thanks for the comment, please give me time to look into other comments.

snipped
> > +    -  Are only specific MAC are received? rte_eth_promiscuous_get()
>                                 ^^^^^^^
>                            can be removed
> 
> What about checking vlan-filters, if any? - that is, if packets have some vlan
> stamped and hardware is configured to filter that.
This is excellent thought; can we work together to add this part once the baseline is added to the guide?

> 
> > +
> > +#. are there NIC specific drops?
> > +    -  Check rte_eth_rx_queue_info_get() for nb_desc, scattered_rx,
> > +    -  Check rte_eth_dev_stats() for Stats per queue
> > +    -  Is stats of other queues shows no change via
> > +       rte_eth_dev_dev_rss_hash_conf_get()
> 
>            Does stat for other queues shows no change via ...
> Or, maybe you intend to say - check stats for all queues in case RSS is
> configured and packets are being distributed to a queue not being listened to.
Yes.

snipped
> > +#. Are we are still seeing low performance
> > +    -  Check if sufficient objects in mempool by rte_mempool_avail_count()
> > +    -  Is failure in some pkt? we might be getting pkts with size > mbuf
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 1) Use packets rather than pkts or pkt
> 2) Did you mean "Is there failure in Rx of packets?" Or, "Packet drops
> being observed?"
> > +       data size. Check rte_pktmbuf_is_continguous()
>                              ^^^^^^^^^^^^^^^^^^^^^^^^^
> I think you intended: rte_pktmbuf_is_contiguous()
Well during field deployment with customer, failing to allow multi-segment has led to drops in virtio and NIC PMD. I will try to rephrase this in a better way.

> 
> > +    -  If user pthread is used to access object access
> > +       rte_mempool_cache_create()
> 
> Maybe I didn't get the point - but, why using rte_mempool_cache_create
> helps in case of external pthreads? Using cache would be applicable in
> all cases (assuming mempool_create(..cache_size=0..).
The API ' rte_mempool_cache_create' is being created for non-eal threads. In use case scenarios where pthreads are created either before or after 'rte_eal_init', it would be useful to use this to isolate the defect is caused from starving the objects in master mempool. 

snipped
> > +
> > +.. note::
> > +  Need to explore:
> 
> Is this section for user to explore? Or, maybe it is a residual from
> your notes?
As shared below, these would other possible areas for the user to explore in continuation of above.

snipped
> 
> 
> Frankly, it is a good attempt, but I think this is more in shape of
> notes right now.
> 
> I do understand that it is never going to be an easy task to list
> troubleshooting steps - that is fairly dependent on env and use-case.
> But, if maybe you can rephrase and add some context to some sections, it
> would give real nice inputs/hints as a point to start with.
This is an attempt to capture and share points for debug and troubleshoot. As rightly pointed out this will be varied for different use cases and scenarios.

In my humble opinion an attempt is made to start with somewhere. If there more scenario and use cases that community can be benefited, we (dpdk community) is free to add the same.

> 
> Again - just my take. And being so delayed, feel free to ignore.
Thanks for understanding. But I will try to accommodate. 

> 
> -
> Shreyansh

  reply	other threads:[~2019-01-04  7:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26  7:08 [dpdk-dev] [PATCH v3 1/2] doc: add svg for debug and troubleshoot guide Vipin Varghese
2018-11-26  7:08 ` [dpdk-dev] [PATCH v3 2/2] doc: add guide for debug and troubleshoot Vipin Varghese
2019-01-04  6:37   ` Shreyansh Jain
2019-01-04  7:01     ` Varghese, Vipin [this message]
2019-01-16 14:54   ` [dpdk-dev] [PATCH v4 0/2] doci/howto: add debug and troubleshoot guide Vipin Varghese
2019-01-16 14:54     ` [dpdk-dev] [PATCH v4 1/2] doc: add svg for " Vipin Varghese
2019-01-16 14:54     ` [dpdk-dev] [PATCH v4 2/2] doc: add guide for debug and troubleshoot Vipin Varghese
2019-01-18 15:28       ` Kovacevic, Marko
2019-01-21  3:38         ` Varghese, Vipin
2019-01-21 10:41       ` [dpdk-dev] [PATCH v5 0/2] doc/howto: add debug and troubleshoot guide Vipin Varghese
2019-01-21 10:41         ` [dpdk-dev] [PATCH v5 1/2] doc: add svg for " Vipin Varghese
2019-01-28  1:08           ` Thomas Monjalon
2019-01-28 14:28             ` Varghese, Vipin
2019-02-19 15:57           ` [dpdk-dev] [PATCH v6 0/2] guide to debug and troubleshoot Vipin Varghese
2019-02-19 15:57             ` [dpdk-dev] [PATCH v6 1/2] doc: add svg for debug and troubleshoot guide Vipin Varghese
2019-02-19 15:57             ` [dpdk-dev] [PATCH v6 2/2] doc: add guide for debug and troubleshoot Vipin Varghese
2019-02-25 11:34               ` Mcnamara, John
2019-02-25 15:46                 ` Varghese, Vipin
2019-01-21 10:41         ` [dpdk-dev] [PATCH v5 " Vipin Varghese
2019-01-28  1:30           ` Thomas Monjalon
2019-01-28 14:51             ` Varghese, Vipin
2019-01-28 15:59               ` Thomas Monjalon
2019-02-08  9:21                 ` Varghese, Vipin

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=4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2E06C1@BGSMSX101.gar.corp.intel.com \
    --to=vipin.varghese@intel.com \
    --cc=amol.patel@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=john.mcnamara@intel.com \
    --cc=marko.kovacevic@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=shreyansh.jain@nxp.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).