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 C36C4282
for <dev@dpdk.org>; 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 <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>
<f7ttwh2numw.fsf@redhat.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: <f7td1nqxhiv.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.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 <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 19:56:59 -0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> 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" <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.
>
> 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