From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 223F45915 for ; Fri, 23 May 2014 04:09:50 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 22 May 2014 19:04:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,890,1392192000"; d="scan'208";a="545286423" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by orsmga002.jf.intel.com with ESMTP; 22 May 2014 19:09:56 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 22 May 2014 19:09:18 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 22 May 2014 19:09:18 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.190]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.192]) with mapi id 14.03.0123.003; Fri, 23 May 2014 10:08:56 +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+fL7JUQaGJQ5tMDyUAgACU5SD//5CLAIABM9HQ Date: Fri, 23 May 2014 02:08:55 +0000 Message-ID: References: <1400739073-32011-1-git-send-email-changchun.ouyang@intel.com> <537DF8DA.5000402@6wind.com> <537E1842.5010207@6wind.com> In-Reply-To: <537E1842.5010207@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: Fri, 23 May 2014 02:09:52 -0000 Hi Ivan To some extent, I also agree with you. But customer hope DPDK can provide an interface like "ifconfig up" and "ifc= onfig down" in linux, They can invoke such an interface in user application to repeated stop and = start dev frequently, and Make sure RX and TX work fine after each start, I think it is not necessary= to do really device start and stop at Each time, just need start and stop RX and TX function, so the straightforw= ard method is to enable and disable tx lazer in ixgbe.=20 But in the ether level we need a more generic api name, here is rte_eth_dev= _admin_link_up/down, while enable_tx_laser is not suitable,=20 Enable and disable tx laser is a way in ixgbe to fulfill the administrative= link up and link down. maybe Fortville and future generation NIC will use other ways to fulfill th= e admin_link_up/down. Thanks and regards, Changchun -----Original Message----- From: Ivan Boule [mailto:ivan.boule@6wind.com]=20 Sent: Thursday, May 22, 2014 11:31 PM To: Ouyang, Changchun; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/3] Support administrative link up and link= down Hi Changchun, On 05/22/2014 04:44 PM, Ouyang, Changchun wrote: > Hi Ivan > For this one, it seems long story for that... > In short, > Some customer have such kind of requirement, they want to repeatedly=20 > start(rte_dev_start) and stop(rte_dev_stop) the port for RX and TX,=20 > but they find after several times start and stop, the RX and TX can't wor= k well even the port starts, and the packets error number increase. > > To resolve this error number increase issue, and let port work fine=20 > even after repeatedly start and stop, We need a new API to do it, after d= iscussing, we have these 2 API, admin link up and admin link down. If I understand well, this "feature" is not needed by itself, but only as a= work-around to address issues when repeatedly invoking the functions ixgbe= _dev_stop and ixgbe_dev_start. Do such issues appear when performing the same operations with the Linux ke= rnel driver? Anyway, I suppose that such functions have to be automatically invoked by t= he same code of the network application that invokes the functions ixgbe_de= v_stop and ixgbe_dev_start (said differently, there is no need for a manual= assistance !) In that case, would not it be possible - and highly preferable - to directl= y invoke the functions ixgbe_disable_tx_laser and, then, ixgbe_enable_tx_la= ser from the appropriate step during the execution of the function ixgbe_de= v_start(), waiting for some appropriate delays between the two operations, = if so needed? Regards, Ivan > > Any difference if use " dev_link_start/stop" or " dev_link_up/down"?=20 > 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 vi= rtio PMD. > > Thanks > Changchun > > > -----Original Message----- > From: Ivan Boule [mailto:ivan.boule@6wind.com] > 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=20 > 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 IXG= BE PMD. >> 3. Add command in testpmd to test the functionality of administrative li= nk up and down of PMD. >> ... > Hi Changchun, > > The 2 functions "rte_eth_dev_admin_link_up" and "rte_eth_dev_admin_link_d= own" > don't have an equivalent in the Linux kernel, thus I am wondering what is= their effective usage from a network application perspective. > Could you briefly explain in which use case these functions can be used f= or? > > By the way, it's not completely evident to infer the exact semantics of t= hese 2 functions from their name. > In particular, I do not see what the term "admin" brings to the understan= ding of their role. If it is to suggest that these functions are intended t= o force the link to a different state of its initial [self-detected] state,= then the term "force" would be more appropriate. > > Otherwise, if eventually these functions appear to be mandatory, I sugges= t to rename them "rte_eth_dev_link_start" and "rte_eth_dev_link_stop" respe= ctively, and to apply the same naming conventions in the 2 other patches. > > It might also be worth documenting in the comment section of the prototyp= e of these 2 functions whether it makes sense or not to support a notion of= link that can be dynamically started or stopped in non-physical PMDs (vmxn= et3, virtio, etc). -- Ivan Boule 6WIND Development Engineer