From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 16B2A9ABE for ; Wed, 25 Feb 2015 06:05:14 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 24 Feb 2015 21:05:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,643,1418112000"; d="scan'208";a="671220422" Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98]) by fmsmga001.fm.intel.com with ESMTP; 24 Feb 2015 21:05:11 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by PGSMSX106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 25 Feb 2015 13:05:10 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.161]) by shsmsx102.ccr.corp.intel.com ([169.254.2.62]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 13:05:10 +0800 From: "Zhou, Danny" To: Tim Deng , "dev@dpdk.org" Thread-Topic: [dpdk-dev] Manage DPDK port capability via KNI Thread-Index: AQHQUJ5eznYPu2PxYkOgNqcfS5yrB50AzjgA Date: Wed, 25 Feb 2015 05:05:08 +0000 Message-ID: References: <15f7ead7.137b.14bbe735a7e.Coremail.dpdkdev@126.com> In-Reply-To: <15f7ead7.137b.14bbe735a7e.Coremail.dpdkdev@126.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Manage DPDK port capability via KNI X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 05:05:15 -0000 You can do it but it will not sync with DPDK. In current KNI implementation= , the devices' I/O address spaces are mapped to both userspace DPDK and kenrelspace KNI, s= o one can control the NIC device independently(using ethtool for KNI and ethdev A= PIs for DPDK) without synchronization. In theory, KNI should route all device control request from ethtool to DPDK= . But unfortunately, a short path is adopted at the moment due to DPDK reused lots of legacy ker= nel codes with BSD license. > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tim Deng > Sent: Wednesday, February 25, 2015 9:57 AM > To: dev@dpdk.org > Subject: [dpdk-dev] Manage DPDK port capability via KNI >=20 > Hi, >=20 >=20 > I am wondering how could we manage a DPDK port offload capabilities, > e.g. if we want to disable TSO capability on a DPDK port, is it feasible > that we use ethtool to configure a KNI then the config will be sync to a = DPDK port? >=20 >=20 > Thanks, > Tim