> -----Original Message-----
> From: Aaron Conole [mailto:aconole at redhat.com]
> Sent: Thursday, June 09, 2016 6:24 PM
> To: Ananyev, Konstantin
> Cc: Pattan, Reshma; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 5/8] lib/librte_pdump: add new library for
> packet capturing support
>
> "Ananyev, Konstantin" <konstantin.ananyev at intel.com> writes:
>
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Aaron Conole
> >> Sent: Thursday, June 09, 2016 4:59 PM
> >> To: Pattan, Reshma
> >> Cc: dev at dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH v6 5/8] lib/librte_pdump: add new
> > library for packet capturing support
> >>
> >> Reshma Pattan <reshma.pattan at intel.com> writes:
> >>
> >> > Added new library for packet capturing support.
> >> >
> >> > Added public api rte_pdump_init, applications should call
> >> > this as part of their application setup to have packet
> >> > capturing framework ready.
> >> >
> >> > Added public api rte_pdump_uninit to uninitialize the packet
> >> > capturing framework.
> >> >
> >> > Added public apis rte_pdump_enable and rte_pdump_disable to
> >> > enable and disable packet capturing on specific port and queue.
> >> >
> >> > Added public apis rte_pdump_enable_by_deviceid and
> >> > rte_pdump_disable_by_deviceid to enable and disable packet
> >> > capturing on a specific device (pci address or name) and queue.
> >> >
> >> > Signed-off-by: Reshma Pattan <reshma.pattan at intel.com>
> >> > ---
> >> > +
> >> > +int
> >> > +rte_pdump_init(void)
> >>
> >> Would you be opposed to having an argument here which takes a path to
> >> the server socket? That way the application can have some control over
> >> the server socket location rather than using the guesses from
> >> pdump_get_socket_path.
> >
> > I suppose it is better to keep IPC mechanism details internal for the
> > pdump library.
> > That way upper layer don't need to know what is that and write the
> > code to open/maintain it.
> > Again, that gives pdump library a freedom to change it (if needed) or
> > possibly introduce some alternatives.
> > Konstantin
> >
>
> How does the application change it? The details do matter here, as some
> applications (ex: openvswitch) have specific policies on which files
> files get opened and where those files exist. That has impact on things
> like selinux and other access control technology.
>
> If I missed the API that lets apps redirect the output, please correct me,
> but so far I don't think I've missed it. pdump still can change a
> default, but it would be good to give a method for guiding the final
> choice of file to open.
No, I think, right now it is not possible to change socket path from the API.
Basically it follows the same logic as generating path for DPDK runtime config,
etc:
/var/run for root, or $HOME dir otherwise.
I suppose if openswitch or any other dpdk app is able to start successfully,
then it should be able to open pdump socket too, correct?
Anyway, as I understand what you suggest:
rte_pdump_init(const char *dir)
{
If (sock_name != NULL) {/*open socket at provided dir path*/}
else { /*generate default pathname for the socket*/
and something similar for client side, might be a new function:
rte_pdump_set_dirpath(const char *dir);
Is that right?
Konstantin
>
> -Aaron
