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

["Varghese, Vipin" <vipin.varghese@intel.com>]

Hi Thomas, John and Marko,

I am working on sharing the next version with grammar checks done with Grammarly. Will update ASAP.

Thanks
Vipin Varghese

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, January 28, 2019 9:30 PM
> To: Varghese, Vipin <vipin.varghese@intel.com>
> Cc: Mcnamara, John <john.mcnamara@intel.com>; Kovacevic, Marko
> <marko.kovacevic@intel.com>; dev@dpdk.org; shreyansh.jain@nxp.com;
> Patel, Amol <amol.patel@intel.com>; Padubidri, Sanjay A
> <sanjay.padubidri@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v5 2/2] doc: add guide for debug and
> troubleshoot
> 
> 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?
> 
>