From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <aconole@redhat.com> Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 6BE4A2951 for <dev@dpdk.org>; Thu, 9 Jun 2016 19:23:53 +0200 (CEST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 BEE5A81F07; Thu, 9 Jun 2016 17:23:52 +0000 (UTC) Received: from aconole-fed23 (dhcp-25-129.bos.redhat.com [10.18.25.129]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u59HNpSa011989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jun 2016 13:23:52 -0400 From: Aaron Conole <aconole@redhat.com> To: "Ananyev\, Konstantin" <konstantin.ananyev@intel.com> Cc: "Pattan\, Reshma" <reshma.pattan@intel.com>, "dev\@dpdk.org" <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> <f7ty46enyk9.fsf@redhat.com> <2601191342CEEE43887BDE71AB97725836B6DAC0@irsmsx105.ger.corp.intel.com> Date: Thu, 09 Jun 2016 13:23:51 -0400 In-Reply-To: <2601191342CEEE43887BDE71AB97725836B6DAC0@irsmsx105.ger.corp.intel.com> (Konstantin Ananyev's message of "Thu, 9 Jun 2016 16:05:34 +0000") Message-ID: <f7ttwh2numw.fsf@redhat.com> 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.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 09 Jun 2016 17:23:52 +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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 09 Jun 2016 17:23:53 -0000 "Ananyev, Konstantin" <konstantin.ananyev@intel.com> 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 <reshma.pattan@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@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. -Aaron