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 4C0B65907 for ; Thu, 22 May 2014 16:44:34 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 22 May 2014 07:44:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,887,1392192000"; d="scan'208";a="516065727" Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36]) by orsmga001.jf.intel.com with ESMTP; 22 May 2014 07:44:39 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 22 May 2014 07:44:38 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 22 May 2014 07:44:38 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.190]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.23]) with mapi id 14.03.0123.003; Thu, 22 May 2014 22:44:36 +0800 From: "Ouyang, Changchun" To: Ivan Boule , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 0/3] Support administrative link up and link down Thread-Index: AQHPdYSyI5IuxyGSuE+fL7JUQaGJQ5tMDyUAgACU5SA= Date: Thu, 22 May 2014 14:44:35 +0000 Message-ID: References: <1400739073-32011-1-git-send-email-changchun.ouyang@intel.com> <537DF8DA.5000402@6wind.com> In-Reply-To: <537DF8DA.5000402@6wind.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] [PATCH 0/3] Support administrative link up and link down 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: Thu, 22 May 2014 14:44:34 -0000 Hi Ivan For this one, it seems long story for that... In short,=20 Some customer have such kind of requirement,=20 they want to repeatedly start(rte_dev_start) and stop(rte_dev_stop) the por= t for RX and TX, but they find after several times start and stop, the RX and TX can't work well even the = port starts, and the packets error number increase. To resolve this error number increase issue, and let port work fine even af= ter repeatedly start and stop, We need a new API to do it, after discussing, we have these 2 API, admin li= nk up and admin link down. Any difference if use " dev_link_start/stop" or " dev_link_up/down"? to me,= admin_link_up/down is better than dev_link_start/stop, If most people think we need change the name, it is ok to rename it. I don't think we need it in non-physical PMDs. So no implementation in virt= io PMD. Thanks Changchun -----Original Message----- From: Ivan Boule [mailto:ivan.boule@6wind.com]=20 Sent: Thursday, May 22, 2014 9:17 PM To: Ouyang, Changchun; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/3] Support administrative link up and link= down On 05/22/2014 08:11 AM, Ouyang Changchun wrote: > This patch series contain the following 3 items: > 1. Add API to support administrative link up and down. > 2. Implement the functionality of administrative link up and down in IXGB= E PMD. > 3. Add command in testpmd to test the functionality of administrative lin= k up and down of PMD. > > Ouyang Changchun (3): > Add API for supporting administrative link up and down. > Implement the functionality of administrative link up and down in > IXGBE PMD. > Add command line to test the functionality of administrative link up > and down of PMD in testpmd. > > app/test-pmd/cmdline.c | 78 ++++++++++++++++++++++++++++++= +++++++ > app/test-pmd/testpmd.c | 14 +++++++ > app/test-pmd/testpmd.h | 2 + > lib/librte_ether/rte_ethdev.c | 38 ++++++++++++++++++ > lib/librte_ether/rte_ethdev.h | 34 ++++++++++++++++ > lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 58 +++++++++++++++++++++++++++ > 6 files changed, 224 insertions(+) > Hi Changchun, The 2 functions "rte_eth_dev_admin_link_up" and "rte_eth_dev_admin_link_dow= n" don't have an equivalent in the Linux kernel, thus I am wondering what is t= heir effective usage from a network application perspective. Could you briefly explain in which use case these functions can be used for= ? By the way, it's not completely evident to infer the exact semantics of the= se 2 functions from their name. In particular, I do not see what the term "admin" brings to the understandi= ng of their role. If it is to suggest that these functions are intended to = force the link to a different state of its initial [self-detected] state, t= hen the term "force" would be more appropriate. Otherwise, if eventually these functions appear to be mandatory, I suggest = to rename them "rte_eth_dev_link_start" and "rte_eth_dev_link_stop" respect= ively, and to apply the same naming conventions in the 2 other patches. It might also be worth documenting in the comment section of the prototype = of these 2 functions whether it makes sense or not to support a notion of l= ink that can be dynamically started or stopped in non-physical PMDs (vmxnet= 3, virtio, etc). Regards, Ivan -- Ivan Boule 6WIND Development Engineer