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

Thomas Monjalon thomas at monjalon.net
Mon Jan 28 16:59:44 CET 2019


28/01/2019 15:51, Varghese, Vipin:
> Hi Thomas,
> 
> snipped
> > 
> > I feel this doc will be updated to provide a complete debug checklist,
> Attempt is made to capture commonly seen filed issue. Saying so, I am clear that I will not be able to identify all debug check list. As time, experience and sharing increases (from the community), I am certain sure this will grow 

Yes this is what I mean.
We just need to give a good start by explaining well the intent and context.

> > > +Debug & Troubleshoot guide via PMD
> > > +==================================
> > 
> > Why "via PMD"? Do we use PMD for troubleshooting?
> I believe yes, we do collect information with enhanced procinfo tool.
> 
> > Or is it dedicated to troubleshoot the PMD behaviour?
> I am not clear with this statement. Hence is the query 'Is this dedicated to troubleshooting Application. PMD and Library uses cases?'

Sorry I don't understand.
I think you can just remove "via PMD" in the title.

[...]
> > > +  *  single primary
> > > +  *  multiple primary
> > > +  *  single primary single secondary
> > > +  *  single primary multiple secondary
> > > +
> > > +In all the above cases, it is a tedious task to isolate, debug and
> > > +understand odd behaviour which occurs randomly or periodically. The
> > > +goal of guide is to share and explore a few commonly seen patterns
> > > +and behaviour. Then, isolate and identify the root cause via step by
> > > +step debug at various processing stages.
> > 
> > I don't understand how this introduction is related to "via PMD" in the title.
> I believe the information is shared ```The goal of guide is to share and explore a few commonly seen patterns and behaviour. Then, isolate and identify the root cause via step by step debug at various processing stages.'```
> 
> There would multiple ways to design application for solving a same problem. These are depended on user, platform, scaling factor and target. These various combinations make use PMD and libraries. Misconfiguration and not taking care of platform will cause throttling and even drops.
> 
> Example: application designed to run on single is now been deployed to run on multi NUMA model.

Yes, so you are explaining there can be a lot of different scenarios.

[...]
> > > +#. Linux 64-bit|32-bit
> > > +#. DPDK PMD and libraries are used
> > 
> > Isn't it always the case with DPDK?
> > 
> > > +#. Libraries and PMD are either static or shared. But not both
> > 
> > Strange assumption. Why would it be both?
> If applications are only build with DPDK libraries, then yes the assumption is correct. But when applications are build using DPDK as one of software layer (example DPDK network stack, DPDK suricata, DPDK hyperscan)  as per my understanding this is not true.

Sorry I don't understand.
The DPDK libraries are either shared or static, but never mixed.
Anyway why is it significant here?

> > > +#. Machine flag optimizations of gcc or compiler are made constant
> > 
> > What do you mean?
> I can reword as ```DPDK and the application libraries are built with same flags. ```

Why is it significant?





More information about the dev mailing list