From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id C237B593A for ; Thu, 22 May 2014 17:31:07 +0200 (CEST) Received: by mail-wg0-f44.google.com with SMTP id a1so3500952wgh.15 for ; Thu, 22 May 2014 08:31:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ia9J2G2ZX5uGLAfvZ+vUtEtK7YHgH265pOigri5X2/U=; b=RYxu/pBTqsvw4aspz+P5W5fTSYc2MFuyrEXvuIpSoBRy92B+lNhsssXB0hrbhZDDYv hu6CqPaJKzd0QPGID1fq5U3oeoIIIrptUpImCEfPnFxPea9oZ5izfdEtfzegzQHSJFWQ mW+UGsGHgwIcf8noqxoOQrsyzyHMkN2LNvMfk3OlB8gGj26Tbjm0eGIfkqBrN47voldO Eup1A+jaGhhHUtU55G4kGDgwlRggJJ9So0j8tWX9avC4CzAIsiNgztGbKy6ZMs2lFaTl Wv6AFvSgJoIB4dtGCIjfqwyZH1vM48/Vb9KuRlkotEqQO+pzn2x16OcUzn3zd4zHdHtR 2QCA== X-Gm-Message-State: ALoCoQmiLIQd7KalVDaVJtUB225JFF01i9IcVDbb5f7vD805895FolvQeEPjqTj7WlOcTIkMCjAC X-Received: by 10.180.206.163 with SMTP id lp3mr16955107wic.29.1400772677183; Thu, 22 May 2014 08:31:17 -0700 (PDT) Received: from [10.16.0.189] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id ek4sm908398wib.9.2014.05.22.08.31.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 08:31:16 -0700 (PDT) Message-ID: <537E1842.5010207@6wind.com> Date: Thu, 22 May 2014 17:31:14 +0200 From: Ivan Boule User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Ouyang, Changchun" , "dev@dpdk.org" References: <1400739073-32011-1-git-send-email-changchun.ouyang@intel.com> <537DF8DA.5000402@6wind.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 15:31:08 -0000 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 start(rte_dev_start) and stop(rte_dev_stop) the port 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 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 ixgbe_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 by the same code of the network application that invokes the functions ixgbe_dev_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 directly 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 virtio 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 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 IXGBE PMD. >> 3. Add command in testpmd to test the functionality of administrative link 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 is 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 understanding 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 suggest to rename them "rte_eth_dev_link_start" and "rte_eth_dev_link_stop" respectively, 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 link that can be dynamically started or stopped in non-physical PMDs (vmxnet3, virtio, etc). -- Ivan Boule 6WIND Development Engineer