[dpdk-dev] [PATCH] pdump: change to use generic multi-process channel

[Tan, Jianfeng]

Thank you for the comments!

> -----Original Message-----
> From: Pattan, Reshma
> Sent: Wednesday, March 21, 2018 12:38 AM
> To: Tan, Jianfeng; dev at dpdk.org
> Subject: RE: [PATCH] pdump: change to use generic multi-process channel
> 
> Hi,
> 
> > -----Original Message-----
> > From: Tan, Jianfeng
> > Sent: Sunday, March 4, 2018 3:04 PM
> > To: dev at dpdk.org
> > Cc: Tan, Jianfeng <jianfeng.tan at intel.com>; Pattan, Reshma
> > <reshma.pattan at intel.com>
> > Subject: [PATCH] pdump: change to use generic multi-process channel
> >
> > The original code replies on the private channel for primary and secondary
> > communication. Change to use the generic multi-process channel.
> >
> > Note with this change, dpdk-pdump will be not compatible with old version
> > DPDK applications.
> >
> 
> Is this the correct time to make this change? As I see the rte_mp APIs are still
> in experimental stage?
> If you wish to change them,
> 
> 1) I feel ABI breakage has to be addressed  first for change in rte_pdump_init() . 
> 2)ABI notice for removal of the rte_pdump_set_socket_dir()  and then remove it completely .

This patch itself does not break any ABI. It just puts parameters of rte_pdump_init() not used. And make rte_pdump_set_socket_dir() as a dummy function.

> 3)Need to do cleanup of the code app/dpdk-pdump.

Yes, I understand it's a normal process to announce deprecation firstly, and then do the change.

But here is the thing, with generic mp introduced, we will not be compatible with DPDK versions.
So we want to unify the use of generic mp channel in this release for vfio, pdump, vdev, memory rework.
And in fact, ABI/API changes could be delayed to later releases.

> 4)After all the changes we need to make sure dpdk-pdump works fine
> without breaking the functionality, validation team should be able to help.

I have done a simple test of pdump. Can you suggest where can I get the comprehensive test cases?

> 5)Replace strcpy  with snprintf.

Will do.

Thanks,
Jianfeng

> 
> Thanks,
> Reshma
>