From patchwork Thu Nov 26 13:51:14 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Pattan, Reshma" X-Patchwork-Id: 84576 X-Patchwork-Delegate: david.marchand@redhat.com 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 5AFA1A052A; Thu, 26 Nov 2020 14:58:00 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3D667C968; Thu, 26 Nov 2020 14:57:59 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id EA4EAC950 for ; Thu, 26 Nov 2020 14:57:56 +0100 (CET) IronPort-SDR: 0nGh9sCT2sBGTVO/Gt+tlLIF76jBfoESCXj1BL6nZl8XINzcuFJQNpsvBfwFoUs06DiLz5b6sT T1VP0w7D4OlQ== X-IronPort-AV: E=McAfee;i="6000,8403,9816"; a="236417662" X-IronPort-AV: E=Sophos;i="5.78,372,1599548400"; d="scan'208";a="236417662" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2020 05:57:54 -0800 IronPort-SDR: 0ZPZ3n4eajgMfVhIv6RINuxTc0O6EP4OHRMlmHP9VYMNRbIfgs6fk3R+LmhLAjfdLnuBnc7UUH Cmf3U5QkYTKw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.78,372,1599548400"; d="scan'208";a="362814393" Received: from silpixa00400214.ir.intel.com (HELO silpixa00400214.ger.corp.intel.com) ([10.237.222.108]) by fmsmga004.fm.intel.com with ESMTP; 26 Nov 2020 05:57:52 -0800 From: Reshma Pattan To: dev@dpdk.org Cc: Reshma Pattan Date: Thu, 26 Nov 2020 13:51:14 +0000 Message-Id: <1606398674-32351-1-git-send-email-reshma.pattan@intel.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1594650325-151798-1-git-send-email-reshma.pattan@intel.com> References: <1594650325-151798-1-git-send-email-reshma.pattan@intel.com> Subject: [dpdk-dev] [PATCH v2] 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 --- v2: fixes for the review comments --- doc/guides/howto/packet_capture_framework.rst | 12 +++---- doc/guides/prog_guide/pdump_lib.rst | 48 +++++++++++---------------- 2 files changed, 25 insertions(+), 35 deletions(-) diff --git a/doc/guides/howto/packet_capture_framework.rst b/doc/guides/howto/packet_capture_framework.rst index 6bd51f6..c31bac5 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,13 +28,13 @@ 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 +capture framework and acts as a server, and the ``dpdk-pdump`` tool acts as a client. 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 diff --git a/doc/guides/prog_guide/pdump_lib.rst b/doc/guides/prog_guide/pdump_lib.rst index 2a0f1f3..3541cac 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 a 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,28 @@ 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 disables 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.