From patchwork Mon Jul 13 14:25:25 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Pattan, Reshma" X-Patchwork-Id: 73951 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id CEBBEA0540; Mon, 13 Jul 2020 16:39:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A699D1D8E4; Mon, 13 Jul 2020 16:39:21 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 08F151D8E3 for ; Mon, 13 Jul 2020 16:39:19 +0200 (CEST) IronPort-SDR: VIGlbQCZD7CL0+kABhO2a8wWS78dJgRKzvs2kcmaiyJkMPpAJMR4p7TDONpKYKjMx3+EmuZctr oOoUXbTez7dw== X-IronPort-AV: E=McAfee;i="6000,8403,9681"; a="128678849" X-IronPort-AV: E=Sophos;i="5.75,347,1589266800"; d="scan'208";a="128678849" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2020 07:39:17 -0700 IronPort-SDR: mzgZtDC+/h5xdZOx5SSGh000eCJxBNjV03hDwMlrwwWNi2yNHIhcXjXAHcvJFVoOQDb/7GLG6G 6wJh1lEwiqBw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,347,1589266800"; d="scan'208";a="485027668" Received: from silpixa00400214.ir.intel.com (HELO silpixa00400214.ger.corp.intel.com) ([10.237.222.108]) by fmsmga006.fm.intel.com with ESMTP; 13 Jul 2020 07:39:16 -0700 From: Reshma Pattan To: dev@dpdk.org Cc: Reshma Pattan Date: Mon, 13 Jul 2020 15:25:25 +0100 Message-Id: <1594650325-151798-1-git-send-email-reshma.pattan@intel.com> X-Mailer: git-send-email 1.8.3.1 Subject: [dpdk-dev] [PATCH] doc: update pdump documentation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Update the pdump library programmers guide and Howto doc with the use of multi process channel replacing socket based communication. Signed-off-by: Reshma Pattan Acked-by: Bruce Richardson --- doc/guides/howto/packet_capture_framework.rst | 16 ++++----- doc/guides/prog_guide/pdump_lib.rst | 49 +++++++++++---------------- 2 files changed, 28 insertions(+), 37 deletions(-) diff --git a/doc/guides/howto/packet_capture_framework.rst b/doc/guides/howto/packet_capture_framework.rst index 946a21c..c941c01 100644 --- a/doc/guides/howto/packet_capture_framework.rst +++ b/doc/guides/howto/packet_capture_framework.rst @@ -19,7 +19,7 @@ Introduction The :ref:`librte_pdump ` library provides the APIs required to allow users to initialize the packet capture framework and to enable or -disable packet capture. The library works on a client/server model and its +disable packet capture. The library works on a multi process communication model and its usage is recommended for debugging purposes. The :ref:`dpdk-pdump ` tool is developed based on the @@ -28,14 +28,14 @@ of enabling or disabling packet capture on DPDK ports. The ``dpdk-pdump`` tool provides command-line options with which users can request enabling or disabling of the packet capture on DPDK ports. -The application which initializes the packet capture framework will act as a -server and the application that enables or disables the packet capture will -act as a client. The server sends the Rx and Tx packets from the DPDK ports -to the client. +The application which initializes the packet capture framework will be a primary process +and the application that enables or disables the packet capture will +be a secondary process. The primary process sends the Rx and Tx packets from the DPDK ports +to the secondary process. -In DPDK the ``testpmd`` application can be used to initialize the packet -capture framework and act as a server, and the ``dpdk-pdump`` tool acts as a -client. To view Rx or Tx packets of ``testpmd``, the application should be +In DPDK the ``testpmd`` application has been initialize with the packet +capture framework and acts as primary process, and the ``dpdk-pdump`` tool acts as a +secondary process. To view Rx or Tx packets of ``testpmd``, the application should be launched first, and then the ``dpdk-pdump`` tool. Packets from ``testpmd`` will be sent to the tool, which then sends them on to the Pcap PMD device and that device writes them to the Pcap file or to an external interface depending diff --git a/doc/guides/prog_guide/pdump_lib.rst b/doc/guides/prog_guide/pdump_lib.rst index 2a0f1f3..227eb1a 100644 --- a/doc/guides/prog_guide/pdump_lib.rst +++ b/doc/guides/prog_guide/pdump_lib.rst @@ -11,8 +11,12 @@ The library does the complete copy of the Rx and Tx mbufs to a new mempool and hence it slows down the performance of the applications, so it is recommended to use this library for debugging purposes. +The library uses generic multi process channel to facilitate communication +between primary and secondary process for enabling/disabling packet capture on +ports. + The library provides the following APIs to initialize the packet capture framework, to enable -or disable the packet capture, and to uninitialize it: +or disable the packet capture, and to uninitialize it. * ``rte_pdump_init()``: This API initializes the packet capture framework. @@ -38,42 +42,29 @@ or disable the packet capture, and to uninitialize it: Operation --------- -The ``librte_pdump`` library works on a client/server model. The server is responsible for enabling or -disabling the packet capture and the clients are responsible for requesting the enabling or disabling of -the packet capture. - -The packet capture framework, as part of its initialization, creates the pthread and the server socket in -the pthread. The application that calls the framework initialization will have the server socket created, -either under the path that the application has passed or under the default path i.e. either ``/var/run/.dpdk`` for -root user or ``~/.dpdk`` for non root user. - -Applications that request enabling or disabling of the packet capture will have the client socket created either under -the path that the application has passed or under the default path i.e. either ``/var/run/.dpdk`` for root user or -``~/.dpdk`` for not root user to send the requests to the server. The server socket will listen for client requests for -enabling or disabling the packet capture. - +The primary process using ``librte_pdump`` is responsible for initializing the packet +capture framework. The packet capture framework, as part of its initialization, creates the +multi process channel to facilitate communication with secondary process, so the +secondary process ``app/pdump`` tool is responsible for enabling and disabling the packet capture on ports. Implementation Details ---------------------- -The library API ``rte_pdump_init()``, initializes the packet capture framework by creating the pdump server by calling -``rte_mp_action_register()`` function. The server will listen to the client requests to enable or disable the -packet capture. +The library API ``rte_pdump_init()``, initializes the packet capture framework by creating the multi process +channel using ``rte_mp_action_register()`` API. The primary process will listen to secondary process requests +to enable or disable the packet capture over the multi process channel. The library APIs ``rte_pdump_enable()`` and ``rte_pdump_enable_by_deviceid()`` enables the packet capture. -On each call to these APIs, the library creates a separate client socket, creates the "pdump enable" request and sends -the request to the server. The server that is listening on the socket will take the request and enable the packet capture -by registering the Ethernet RX and TX callbacks for the given port or device_id and queue combinations. -Then the server will mirror the packets to the new mempool and enqueue them to the rte_ring that clients have passed -to these APIs. The server also sends the response back to the client about the status of the request that was processed. -After the response is received from the server, the client socket is closed. +For the calls to these APIs from secondary process, the library creates the "pdump enable" request and sends +the request to the primary process over the multi process channel, the primary process takes this request +and enables the packet capture by registering the Ethernet RX and TX callbacks for the given port or device_id +and queue combinations. Then the primary process will mirror the packets to the new mempool and enqueue them to +the rte_ring that secondary process have passed to these APIs. The library APIs ``rte_pdump_disable()`` and ``rte_pdump_disable_by_deviceid()`` disables the packet capture. -On each call to these APIs, the library creates a separate client socket, creates the "pdump disable" request and sends -the request to the server. The server that is listening on the socket will take the request and disable the packet -capture by removing the Ethernet RX and TX callbacks for the given port or device_id and queue combinations. The server -also sends the response back to the client about the status of the request that was processed. After the response is -received from the server, the client socket is closed. +For the calls to these APIs from secondary process, the library creates the "pdump disable" request and sends +the request to the primary process over the multi process channel, the primary process takes this request and disable +the packet capture by removing the Ethernet RX and TX callbacks for the given port or device_id and queue combinations. The library API ``rte_pdump_uninit()``, uninitializes the packet capture framework by calling ``rte_mp_action_unregister()`` function.