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 C3BB35932 for ; Wed, 28 May 2014 03:42:53 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 27 May 2014 18:37:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,924,1392192000"; d="scan'208";a="547520363" Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54]) by orsmga002.jf.intel.com with ESMTP; 27 May 2014 18:43:03 -0700 Received: from fmsmsx119.amr.corp.intel.com (10.19.9.28) by FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 27 May 2014 18:43:03 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by FMSMSX119.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 27 May 2014 18:43:02 -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; Wed, 28 May 2014 09:43:00 +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///4FACAB9/rgA== Date: Wed, 28 May 2014 01:42:59 +0000 Message-ID: References: <1400739073-32011-1-git-send-email-changchun.ouyang@intel.com> <537DF8DA.5000402@6wind.com> <537E1842.5010207@6wind.com> <537F13D4.4030901@6wind.com> In-Reply-To: <537F13D4.4030901@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: Wed, 28 May 2014 01:42:54 -0000 Hi Ivan, Thanks very much for your detailed response for this issue, I think your recommendation makes sense, and I will update the naming and r= e-send a patch for link-up and link-down. Best regards, Changchun -----Original Message----- From: Ivan Boule [mailto:ivan.boule@6wind.com]=20 Sent: Friday, May 23, 2014 5:25 PM To: Ouyang, Changchun; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/3] Support administrative link up and link= down On 05/23/2014 04:08 AM, Ouyang, Changchun wrote: > Hi Ivan > > To some extent, I also agree with you. > But customer hope DPDK can provide an interface like "ifconfig up" and=20 > "ifconfig down" in linux, They can invoke such an interface in user=20 > application to repeated stop and start dev frequently, and Make sure=20 > RX and TX work fine after each start, I think it is not necessary to=20 > do really device start and stop at Each time, just need start and stop RX= and TX function, so the straightforward method is to enable and disable tx= lazer in ixgbe. > But in the ether level we need a more generic api name, here is=20 > rte_eth_dev_admin_link_up/down, while enable_tx_laser is not suitable, En= able and disable tx laser is a way in ixgbe to fulfill the administrative l= ink up and link down. > maybe Fortville and future generation NIC will use other ways to fulfill = the admin_link_up/down. > Hi Changchun, I do not understand what your customer effectively needs. First of all, if I understand well, your customer's application does not re= ally need to invoke the DPDK functions "eth_dev_stop" and "eth_dev_start" f= or addressing its problem, for instance to reconfigure RX/TX queues of the = port. When considering the implementation in the ixgbe PMD of the function "rte_e= th_dev_admin_link_down", its only visible effects from the DPDK application= perspective is that no input packet can be received anymore, and output pa= ckets cannot be transmitted (once having filled the TX queues). Conversely, the only visible effect of the "rte_eth_dev_admin_link_up" function is that input packets are received again, and that output packets = can be successfully transmitted. In fact, by disabling the TX laser on a ixgbe port, the only interesting ef= fect of the function "rte_eth_dev_admin_link_down" is that it notifies the = peer system of a hardware link DOWN event (with no physical link unplug on = the peer side). Conversely, by enabling the TX laser on a ixgbe port, the only interesting = effect of the function "rte_eth_dev_admin_link_up" is that it notifies the = peer system of a hardware link UP event. Is that the actions that your customer's application actually needs to perf= orm? If so, then this certainly deserves a real operational use case that i= t is worth describing in the patch log. This would help DPDK PMD implementors to understand what such functions can= be used for, and to decide whether they actually need to be supported by t= he PMD. Assuming that these 2 functions need to be provided to address the issue de= scribed above, I do not think that the word "admin" brings anything for und= erstanding their role. In fact, the word "admin" rather suggests a pure "so= ftware" down/up setting, instead of a physical one. Naming these 2 functions "rte_eth_dev_set_link_down" and "rte_eth_dev_set_link_up" better describes their expected effect. Regards, Ivan > > 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 >> 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 wo= rk 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 = discussing, 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 ixg= be_dev_stop and ixgbe_dev_start. > Do such issues appear when performing the same operations with the Linux = kernel driver? > > Anyway, I suppose that such functions have to be automatically invoked=20 > by the same code of the network application that invokes the functions=20 > ixgbe_dev_stop and ixgbe_dev_start (said differently, there is no need=20 > for a manual assistance !) > > In that case, would not it be possible - and highly preferable - to direc= tly invoke the functions ixgbe_disable_tx_laser and, then, ixgbe_enable_tx_= laser from the appropriate step during the execution of the function ixgbe_= dev_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"? >> 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 v= irtio 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=20 >> 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 IX= GBE PMD. >>> 3. Add command in testpmd to test the functionality of administrative l= ink up and down of PMD. >>> > ... > >> Hi Changchun, >> >> The 2 functions "rte_eth_dev_admin_link_up" and "rte_eth_dev_admin_link_= down" >> don't have an equivalent in the Linux kernel, thus I am wondering what i= s their 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 = these 2 functions from their name. >> In particular, I do not see what the term "admin" brings to the understa= nding 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= , then the term "force" would be more appropriate. >> >> Otherwise, if eventually these functions appear to be mandatory, I sugge= st to rename them "rte_eth_dev_link_start" and "rte_eth_dev_link_stop" resp= ectively, and to apply the same naming conventions in the 2 other patches. >> >> It might also be worth documenting in the comment section of the prototy= pe of these 2 functions whether it makes sense or not to support a notion o= f link that can be dynamically started or stopped in non-physical PMDs (vmx= net3, virtio, etc). > > > -- > Ivan Boule > 6WIND Development Engineer > -- Ivan Boule 6WIND Development Engineer