From: Jiri Pirko <jpirko@redhat.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: "Ben Hutchings" <bhutchings@solarflare.com>,
"Ben Greear" <greearb@candelatech.com>,
"Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>,
"Michał Mirosław" <mirqus@gmail.com>,
netdev@vger.kernel.org, davem@davemloft.net,
eric.dumazet@gmail.com
Subject: Re: [patch net-next-2.6 1/2] net: allow to change carrier via sysfs
Date: Thu, 1 Sep 2011 07:46:16 +0200 [thread overview]
Message-ID: <20110901054616.GB1969@minipsycho> (raw)
In-Reply-To: <20110831144023.6361de56@nehalam.ftrdhcpuser.net>
Wed, Aug 31, 2011 at 11:40:23PM CEST, shemminger@vyatta.com wrote:
>On Wed, 31 Aug 2011 22:36:45 +0100
>Ben Hutchings <bhutchings@solarflare.com> wrote:
>
>> On Wed, 2011-08-31 at 13:48 -0700, Ben Greear wrote:
>> > On 08/31/2011 01:31 PM, Nicolas de Pesloüan wrote:
>> > > Le 31/08/2011 22:12, Ben Hutchings a écrit :
>> > >> On Wed, 2011-08-31 at 22:03 +0200, Nicolas de Pesloüan wrote:
>> > >>> Le 31/08/2011 10:45, Jiri Pirko a écrit :
>> > >>>
>> > >>>>>>> Do you expect drivers using implementation different than just calling
>> > >>>>>>> netif_carrier_on/off? Or is it supposed to also e.g. power down PHYs?
>> > >>>>>> Yes, generally it can be used also for en/disable phy, for testing
>> > >>>>>> purposes if hw and driver would support it.
>> > >>>>>
>> > >>>>> I'd like to see this working for GRE tunnel devices (for keepalive
>> > >>>>> daemon to be able to indicate to routing daemons whether tunnel is
>> > >>>>> really working) - implementation would be identical to dummy's case.
>> > >>>>> Should I prepare a patch or can I leave it to you?
>> > >>>>
>> > >>>> Ok, I can include it to this patchset (I'm going to repost first patch
>> > >>>> anyway)
>> > >>>
>> > >>> Can't we assume that the dummy's case is the default behavior and
>> > >>> register this default
>> > >>> ndo_change_carrier callback for every device ?
>> > >>
>> > >> You have got to be joking. No device driver that has real link
>> > >> monitoring should use this implementation.
>> > >
>> > > Well, why not? Arguably, this is probably not the feature one would use every day, but...
>> > >
>> > > Testing a cluster reaction to a link down event would be easier if one doesn't need to unplug the cable for the test. I understand that one can turn off the
>> > > switch port (physical or virtual), but echo 0 > /sys/class/net/eth0/carrier would be nice too.
>> >
>> > There is special hardware out there that can do bypass, and often it also has a mode
>> > that will programatically cut link by throwing some relays. We use this for our
>> > testing equipment...
>> >
>> > If there is some way to twiddle standard-ish hardware to actually drop link, that
>> > would be neat. I'd think it should be an ethtool type of thing, however.
>>
>> We need to be able to control this as part of our driver test suite (on
>> the peer, not the device under test). There are various MDIO bits that
>> look like they should do this but unfortunately they don't have
>> consistent effects. Besides that, many PHYs are not MDIO-manageable.
>> So this would have to be a device-specific operation, whether it's
>> exposed through ethtool or sysfs.
>>
>> > Actually dropping link, and letting that naturally propagate up the stack seems
>> > more reasonable than lying about the status half way up the stack.
>>
>
>For testing clustering, there are hooks in vmware and QEMU/KVM to allow
>dropping carrier on the VM side.
Afaik in kvm this is only possible on emulated e1000 (last time I
checked).
next prev parent reply other threads:[~2011-09-01 5:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-30 14:46 [patch net-next-2.6 0/2] net: allow to change carrier via sysfs Jiri Pirko
2011-08-30 14:46 ` [patch net-next-2.6 1/2] " Jiri Pirko
2011-08-30 15:14 ` Ben Hutchings
2011-08-30 15:19 ` Jiri Pirko
2011-08-30 18:11 ` Michał Mirosław
2011-08-30 18:25 ` Stephen Hemminger
2011-08-31 8:31 ` Jiri Pirko
2011-08-31 8:26 ` Jiri Pirko
2011-08-31 8:33 ` Michał Mirosław
2011-08-31 8:45 ` Jiri Pirko
2011-08-31 20:03 ` Nicolas de Pesloüan
2011-08-31 20:12 ` Ben Hutchings
2011-08-31 20:26 ` Jiri Pirko
2011-08-31 20:31 ` Nicolas de Pesloüan
2011-08-31 20:44 ` Ben Hutchings
2011-08-31 20:48 ` Ben Greear
2011-08-31 21:36 ` Ben Hutchings
2011-08-31 21:40 ` Stephen Hemminger
2011-09-01 5:46 ` Jiri Pirko [this message]
2011-08-31 21:49 ` Ben Greear
2011-09-01 5:44 ` Jiri Pirko
2011-08-30 14:46 ` [patch net-next-2.6 2/2] dummy: implement carrier change Jiri Pirko
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=20110901054616.GB1969@minipsycho \
--to=jpirko@redhat.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=greearb@candelatech.com \
--cc=mirqus@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.2p.debian@gmail.com \
--cc=shemminger@vyatta.com \
/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