[dpdk-dev] [PATCH v6 5/8] lib/librte_pdump: add new library for packet capturing support

Aaron Conole aconole at redhat.com
Thu Jun 9 21:56:56 CEST 2016


"Ananyev, Konstantin" <konstantin.ananyev at intel.com> writes:

>> -----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?

Something like that, yes.

> Konstantin
>  
>> 
>> -Aaron


More information about the dev mailing list