All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevic@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH] net: Fix link state inter-dependencies between NIC and backend
Date: Thu, 02 Apr 2015 09:09:35 -0400	[thread overview]
Message-ID: <551D3F8F.1090409@redhat.com> (raw)
In-Reply-To: <20150402092103.GE20229@stefanha-thinkpad.redhat.com>

On 04/02/2015 05:21 AM, Stefan Hajnoczi wrote:
> On Thu, Apr 02, 2015 at 08:11:15AM +0200, Michael S. Tsirkin wrote:
>> On Wed, Apr 01, 2015 at 07:55:38PM -0400, Vladislav Yasevich wrote:
>>> Commit 02d38fcb2caa4454cf4ed728d5908c3cc9ba47be
>>>     net: Update netdev peer on link change
>>>
>>> introduced a link state dependency between the backend
>>> netdev and the nic.  If the admin turned off the link
>>> on the backend, the nic link state was set to down because
>>> the link had no access to the network at all.  This created
>>> some inconsitet behavior for someone who wanted to play
>>> around the links states.
>>>  1) Turning off the nic link and then turning on the backend
>>>     link (even if it was already on) would turn on the nic link
>>>     again.
>>>  2) Turning off the backend link and then turning on the nic
>>>     link would turn on the link in the VM, but would not change
>>>     the backend state resulting in a broken/unreachable network.
>>>
>>> This patch attempts to correct these behaviors.  The patch treats
>>> the nic-backend relationship as two ends of a wire.  Each end tracks
>>> the administratively set link state in addition to actual link
>>> state.  Thus is is possible to set link down at each end effectively
>>> emulating plugging/unplugging the wire at either end.  The patch
>>> continues to preserve the old behavior where setting just
>>> nic side down does NOT impact the backend.
>>>
>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>>
>> I never understood the point of
>> 02d38fcb2caa4454cf4ed728d5908c3cc9ba47be.
>>
>> If you want to tell guest link is down,
>> just set the nic link down.
>>
>> How about we just revert it?
>>
>> Then one can change link state on each end
>> independently, with no notification,
>> and no state to track.
> 
> I agree.  The simple solution would be nice, unless you are aware of a
> use case where it causes problems.

It causes problems when the user turns off link on the backend.  Problems range from much
longer boot up times on older VMs to Windows networks not working.

The problem is the if you turn off the link on the backend, the link to the VM stays
up but can't really reach the network.

Now, you could say "Don't do this" and document it, but it's still ugly and causes
issues.

We could disable the link state change on backends and only allow it on NIC type devices.
That would also solve this.

-vlad
> 
> Stefan
> 

  reply	other threads:[~2015-04-02 13:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-01 23:55 [Qemu-devel] [PATCH] net: Fix link state inter-dependencies between NIC and backend Vladislav Yasevich
2015-04-02  6:11 ` Michael S. Tsirkin
2015-04-02  9:21   ` Stefan Hajnoczi
2015-04-02 13:09     ` Vlad Yasevich [this message]
2015-04-06  6:16       ` Michael S. Tsirkin
2015-04-02  9:21 ` Stefan Hajnoczi

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=551D3F8F.1090409@redhat.com \
    --to=vyasevic@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.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 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.