From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Conole Subject: Re: [PATCH v6 5/8] lib/librte_pdump: add new library for packet capturing support Date: Thu, 09 Jun 2016 15:56:56 -0400 Message-ID: References: <1465393107-32587-1-git-send-email-reshma.pattan@intel.com> <1465462210-4203-1-git-send-email-reshma.pattan@intel.com> <1465462210-4203-6-git-send-email-reshma.pattan@intel.com> <2601191342CEEE43887BDE71AB97725836B6DAC0@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725836B6DD62@irsmsx105.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain Cc: "Pattan\, Reshma" , "dev\@dpdk.org" To: "Ananyev\, Konstantin" Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id C36C4282 for ; Thu, 9 Jun 2016 21:56:58 +0200 (CEST) In-Reply-To: <2601191342CEEE43887BDE71AB97725836B6DD62@irsmsx105.ger.corp.intel.com> (Konstantin Ananyev's message of "Thu, 9 Jun 2016 19:32:55 +0000") List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" "Ananyev, Konstantin" writes: >> -----Original Message----- >> From: Aaron Conole [mailto:aconole@redhat.com] >> Sent: Thursday, June 09, 2016 6:24 PM >> To: Ananyev, Konstantin >> Cc: Pattan, Reshma; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v6 5/8] lib/librte_pdump: add new >> library for packet capturing support >> >> "Ananyev, Konstantin" writes: >> >> >> -----Original Message----- >> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Aaron Conole >> >> Sent: Thursday, June 09, 2016 4:59 PM >> >> To: Pattan, Reshma >> >> Cc: dev@dpdk.org >> >> Subject: Re: [dpdk-dev] [PATCH v6 5/8] lib/librte_pdump: add new >> > library for packet capturing support >> >> >> >> Reshma Pattan 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 >> >> > --- >> >> > + >> >> > +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