From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Conole Subject: Re: [PATCH v8 5/8] lib/librte_pdump: add new library for packet capturing support Date: Mon, 13 Jun 2016 09:28:44 -0400 Message-ID: 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> <3AEA2BF9852C6F48A459DA490692831F0104CD7F@IRSMSX109.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain Cc: "dev\@dpdk.org" To: "Pattan\, Reshma" Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id D75BA5477 for ; Mon, 13 Jun 2016 15:28:46 +0200 (CEST) In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F0104CD7F@IRSMSX109.ger.corp.intel.com> (Reshma Pattan's message of "Fri, 10 Jun 2016 22:14:39 +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" "Pattan, Reshma" writes: > Hi, > >> -----Original Message----- >> From: Aaron Conole [mailto:aconole@redhat.com] >> Sent: Friday, June 10, 2016 7:48 PM >> To: Pattan, Reshma >> 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 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 >>