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 D75BA5477 for <dev@dpdk.org>; Mon, 13 Jun 2016 15:28:46 +0200 (CEST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 51225C049D59; Mon, 13 Jun 2016 13:28:46 +0000 (UTC) Received: from aconole-fed23 (dhcp-25-2.bos.redhat.com [10.18.25.2]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5DDSjkL031130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Jun 2016 09:28:45 -0400 From: Aaron Conole <aconole@redhat.com> To: "Pattan\, Reshma" <reshma.pattan@intel.com> Cc: "dev\@dpdk.org" <dev@dpdk.org> References: <1465487895-5870-1-git-send-email-reshma.pattan@intel.com> <1465575534-23605-1-git-send-email-reshma.pattan@intel.com> <1465575534-23605-6-git-send-email-reshma.pattan@intel.com> <f7ta8is7ue5.fsf@redhat.com> <3AEA2BF9852C6F48A459DA490692831F0104CD7F@IRSMSX109.ger.corp.intel.com> Date: Mon, 13 Jun 2016 09:28:44 -0400 In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F0104CD7F@IRSMSX109.ger.corp.intel.com> (Reshma Pattan's message of "Fri, 10 Jun 2016 22:14:39 +0000") Message-ID: <f7ttwgx9q0j.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.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 13 Jun 2016 13:28:46 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v8 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: Mon, 13 Jun 2016 13:28:47 -0000 "Pattan, Reshma" <reshma.pattan@intel.com> writes: > Hi, > >> -----Original Message----- >> From: Aaron Conole [mailto:aconole@redhat.com] >> Sent: Friday, June 10, 2016 7:48 PM >> To: Pattan, Reshma <reshma.pattan@intel.com> >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v8 5/8] lib/librte_pdump: add new library for >> packet capturing support >> >> Hi Reshma, >> >> 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. >> > >> > Added public api rte_pdump_set_socket_dir to set the server socket >> > path. >> >> Thanks for this, it is quite useful! I am wondering, should the >> same API work for >> a client socket as well? The code becomes a bit easier to maintain, >> and the API >> behaves whether executed from client or server. >> Thoughts? > > In this patch, server socket path is added as argument to > rte_pdump_init() , so server socket path must be passed while calling > rte_pdump_init() API. > And rte_pdump_set_socket_dir() is added for clients , as client need > to know server socket path for contacting server, so application > should pass server socket path for clients using this API. > > Could you please clarify which of the below option you are looking to have? > a)If you want to have client and server sockets under same non default > path this can be done using same API. This just needs a tiny change in > the code. > > b)But if you want to have aserver and client sockets under different > paths, this can done using either of the below approaches. > b1)use same rte_pdump_set_socket_dir() API, but add a new argument to > specify if the path is for server or client socket. This is probably the better option. I think it would result in the least surprise to an end developer, anyway. Thanks, Aaron > (or) > b2)have two separate APIs to set client and server socket paths. > > Which one do you prefer? > > Konstantin, any comments from your side, please add. > > Thanks, > Reshma > >> >> Thanks, >> Aaron >>