DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ivan Boule <ivan.boule@6wind.com>
To: "Ouyang, Changchun" <changchun.ouyang@intel.com>,
	 "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/3] Support administrative link up and link down
Date: Thu, 22 May 2014 17:31:14 +0200	[thread overview]
Message-ID: <537E1842.5010207@6wind.com> (raw)
In-Reply-To: <F52918179C57134FAEC9EA62FA2F9625117AABD8@shsmsx102.ccr.corp.intel.com>

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

  reply	other threads:[~2014-05-22 15:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22  6:11 Ouyang Changchun
2014-05-22  6:11 ` [dpdk-dev] [PATCH 1/3] ether: Add API to support administrative link up and down Ouyang Changchun
2014-05-22  6:11 ` [dpdk-dev] [PATCH 2/3] ixgbe: Implement the functionality of administrative link up and down in IXGBE PMD Ouyang Changchun
2014-05-22  6:11 ` [dpdk-dev] [PATCH 3/3] testpmd: Add commands to test administrative link up and down of PMD Ouyang Changchun
2014-05-22 13:17 ` [dpdk-dev] [PATCH 0/3] Support administrative link up and link down Ivan Boule
2014-05-22 14:44   ` Ouyang, Changchun
2014-05-22 15:31     ` Ivan Boule [this message]
2014-05-23  2:08       ` Ouyang, Changchun
2014-05-23  9:24         ` Ivan Boule
2014-05-28  1:42           ` Ouyang, Changchun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=537E1842.5010207@6wind.com \
    --to=ivan.boule@6wind.com \
    --cc=changchun.ouyang@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).