[dpdk-dev] [PATCH v3 2/2] doc: add guide for debug and troubleshoot

[Varghese, Vipin]

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