From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 66320A0E0 for ; Fri, 26 May 2017 18:52:40 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 May 2017 09:52:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,398,1491289200"; d="scan'208";a="91792860" Received: from silpixa00372839.ir.intel.com (HELO silpixa00372839.ger.corp.intel.com) ([10.237.222.154]) by orsmga004.jf.intel.com with ESMTP; 26 May 2017 09:52:38 -0700 From: Ferruh Yigit To: dev@dpdk.org Cc: Ferruh Yigit Date: Fri, 26 May 2017 17:52:28 +0100 Message-Id: <20170526165228.96919-1-ferruh.yigit@intel.com> X-Mailer: git-send-email 2.9.3 Subject: [dpdk-dev] [RFC] Kernel Control Path (KCP) 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: , X-List-Received-Date: Fri, 26 May 2017 16:52:41 -0000 We are looking for re-sending [1] the Kernel Control Path (KCP) with some updates [2]. Mainly this is an usability improvement for DPDK. And a quick reminder about what KCP is: "KCP is Linux virtual network interface that can control DPDK ports". So DPDK interfaces, somehow will be visible and it will be possible to use common Linux tools on DPDK interfaces. This work can be done in multiple steps: - At first step virtual interfaces can be read-only, and can be used to get stats / information from DPDK ports. - Second step can be controlling the DPDK interfaces in a common way like Linux interfaces. It is good to remind that KCP is only for control path, and no data traffic will be available on those interfaces, meaning not able to use tcpdump or similar tools on those interfaces. I would like to hear about comments, requirements and objection about the idea? Also the name "Kernel Control Path" can be too broad, I am open to a name change, any comments on naming is welcome. [1] http://dpdk.org/ml/archives/dev/2016-March/035139.html [2] Updates planned to the latest version sent: - Create control interfaces without requiring an API call from user application, this will let DPDK applications have this support without any modification. - Default enabled interfaces will be read-only. - Possible rename. Thanks, ferruh Ferruh Yigit (4): ethtool: move from sample folder to lib folder kcp: add kernel control path kernel module rte_ctrl_if: add control interface library ethdev: add control interface support -- 2.9.3