From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 73E5C11D9 for ; Thu, 9 Jun 2016 21:33:24 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 09 Jun 2016 12:32:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,446,1459839600"; d="scan'208";a="994538183" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga002.jf.intel.com with ESMTP; 09 Jun 2016 12:32:57 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.51]) by IRSMSX152.ger.corp.intel.com ([169.254.6.247]) with mapi id 14.03.0248.002; Thu, 9 Jun 2016 20:32:56 +0100 From: "Ananyev, Konstantin" To: Aaron Conole CC: "Pattan, Reshma" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v6 5/8] lib/librte_pdump: add new library for packet capturing support Thread-Index: AQHRwnO0+weyMmyUwEGW9IgrYcI3Zp/haBBg Date: Thu, 9 Jun 2016 19:32:55 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B6DD62@irsmsx105.ger.corp.intel.com> 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> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:33:25 -0000 > -----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 >=20 > "Ananyev, Konstantin" writes: >=20 > >> -----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 ove= r > >> 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 > > >=20 > 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. >=20 > 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 AP= I. Basically it follows the same logic as generating path for DPDK runtime con= fig, 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 !=3D 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 =20 >=20 > -Aaron