All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Boule <ivan.boule-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
To: "Ouyang,
	Changchun"
	<changchun.ouyang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"dev-VfR2kkLFssw@public.gmane.org"
	<dev-VfR2kkLFssw@public.gmane.org>
Subject: Re: [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-E2R4CRU6q/6iAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org>

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-pdR9zngts4EAvxtiuMwx3w@public.gmane.org]
> Sent: Thursday, May 22, 2014 9:17 PM
> To: Ouyang, Changchun; dev-VfR2kkLFssw@public.gmane.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

  parent 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 [PATCH 0/3] Support administrative link up and link down Ouyang Changchun
     [not found] ` <1400739073-32011-1-git-send-email-changchun.ouyang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-05-22  6:11   ` [PATCH 1/3] ether: Add API to support administrative link up and down Ouyang Changchun
2014-05-22  6:11   ` [PATCH 2/3] ixgbe: Implement the functionality of administrative link up and down in IXGBE PMD Ouyang Changchun
2014-05-22  6:11   ` [PATCH 3/3] testpmd: Add commands to test administrative link up and down of PMD Ouyang Changchun
2014-05-22 13:17   ` [PATCH 0/3] Support administrative link up and link down Ivan Boule
     [not found]     ` <537DF8DA.5000402-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2014-05-22 14:44       ` Ouyang, Changchun
     [not found]         ` <F52918179C57134FAEC9EA62FA2F9625117AABD8-E2R4CRU6q/6iAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-05-22 15:31           ` Ivan Boule [this message]
     [not found]             ` <537E1842.5010207-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2014-05-23  2:08               ` Ouyang, Changchun
     [not found]                 ` <F52918179C57134FAEC9EA62FA2F9625117AAEFA-E2R4CRU6q/6iAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-05-23  9:24                   ` Ivan Boule
     [not found]                     ` <537F13D4.4030901-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
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-pdr9zngts4eavxtiumwx3w@public.gmane.org \
    --cc=changchun.ouyang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.