From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4A669D47B3; Thu, 9 Jun 2016 19:56:58 +0000 (UTC) Received: from aconole-fed23 (dhcp-25-129.bos.redhat.com [10.18.25.129]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u59Juv7K013145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jun 2016 15:56:57 -0400 From: Aaron Conole To: "Ananyev\, Konstantin" Cc: "Pattan\, Reshma" , "dev\@dpdk.org" 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> Date: Thu, 09 Jun 2016 15:56:56 -0400 In-Reply-To: <2601191342CEEE43887BDE71AB97725836B6DD62@irsmsx105.ger.corp.intel.com> (Konstantin Ananyev's message of "Thu, 9 Jun 2016 19:32:55 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 09 Jun 2016 19:56:58 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v6 5/8] lib/librte_pdump: add new library for packet capturing support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 19:56:59 -0000 "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