All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Haiyang Zhang <haiyangz@microsoft.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, kys@microsoft.com,
	olaf@aepfle.de, linux-kernel@vger.kernel.org,
	driverdev-devel@linuxdriverproject.org
Subject: Re: [PATCH net-next] hv_netvsc: Increase delay for RNDIS_STATUS_NETWORK_CHANGE
Date: Wed, 03 Feb 2016 14:05:54 +0100	[thread overview]
Message-ID: <87si1ax7t9.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <1454458556-10591-1-git-send-email-haiyangz@microsoft.com> (Haiyang Zhang's message of "Tue, 2 Feb 2016 16:15:56 -0800")

Haiyang Zhang <haiyangz@microsoft.com> writes:

> We simulates a link down period for RNDIS_STATUS_NETWORK_CHANGE message to
> trigger DHCP renew. User daemons may need multiple seconds to trigger the
> link down event. (e.g. ifplugd: 5sec, network-manager: 4sec.) So update
> this link down period to 10 sec to properly trigger DHCP renew.
>

I probably don't follow: why do we need sucha a delay? If (with real
hardware) you plug network cable out and in one second you plug it in
you'll get DHCP renewed, right?

When I introduced RNDIS_STATUS_NETWORK_CHANGE handling by emulating a
pair of up/down events I put 2 second delay to make link_watch happy (as
we only handle 1 event per second there) but 10 seconds sounds to much
to me.

> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
>  drivers/net/hyperv/netvsc_drv.c |   10 ++++++++--
>  1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 1d3a665..6f23973 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -43,6 +43,8 @@
>
>  #define RING_SIZE_MIN 64
>  #define LINKCHANGE_INT (2 * HZ)
> +/* Extra delay for RNDIS_STATUS_NETWORK_CHANGE: */
> +#define LINKCHANGE_DELAY (8 * HZ)
>  static int ring_size = 128;
>  module_param(ring_size, int, S_IRUGO);
>  MODULE_PARM_DESC(ring_size, "Ring buffer size (# of pages)");
> @@ -964,6 +966,7 @@ static void netvsc_link_change(struct work_struct *w)
>  		return;
>  	}
>  	ndev_ctx->last_reconfig = jiffies;
> +	delay = LINKCHANGE_INT;
>
>  	spin_lock_irqsave(&ndev_ctx->lock, flags);
>  	if (!list_empty(&ndev_ctx->reconfig_events)) {
> @@ -1009,8 +1012,11 @@ static void netvsc_link_change(struct work_struct *w)
>  			netif_tx_stop_all_queues(net);
>  			event->event = RNDIS_STATUS_MEDIA_CONNECT;
>  			spin_lock_irqsave(&ndev_ctx->lock, flags);
> -			list_add_tail(&event->list, &ndev_ctx->reconfig_events);
> +			list_add(&event->list, &ndev_ctx->reconfig_events);

Why? Adding to tail was here to not screw the order of events...

>  			spin_unlock_irqrestore(&ndev_ctx->lock, flags);
> +
> +			ndev_ctx->last_reconfig += LINKCHANGE_DELAY;
> +			delay = LINKCHANGE_INT + LINKCHANGE_DELAY;
>  			reschedule = true;
>  		}
>  		break;
> @@ -1025,7 +1031,7 @@ static void netvsc_link_change(struct work_struct *w)
>  	 * second, handle next reconfig event in 2 seconds.
>  	 */
>  	if (reschedule)
> -		schedule_delayed_work(&ndev_ctx->dwork, LINKCHANGE_INT);
> +		schedule_delayed_work(&ndev_ctx->dwork, delay);
>  }
>
>  static void netvsc_free_netdev(struct net_device *netdev)

-- 
  Vitaly

WARNING: multiple messages have this Message-ID (diff)
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Haiyang Zhang <haiyangz@microsoft.com>
Cc: olaf@aepfle.de, netdev@vger.kernel.org,
	driverdev-devel@linuxdriverproject.org,
	linux-kernel@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH net-next] hv_netvsc: Increase delay for RNDIS_STATUS_NETWORK_CHANGE
Date: Wed, 03 Feb 2016 14:05:54 +0100	[thread overview]
Message-ID: <87si1ax7t9.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <1454458556-10591-1-git-send-email-haiyangz@microsoft.com> (Haiyang Zhang's message of "Tue, 2 Feb 2016 16:15:56 -0800")

Haiyang Zhang <haiyangz@microsoft.com> writes:

> We simulates a link down period for RNDIS_STATUS_NETWORK_CHANGE message to
> trigger DHCP renew. User daemons may need multiple seconds to trigger the
> link down event. (e.g. ifplugd: 5sec, network-manager: 4sec.) So update
> this link down period to 10 sec to properly trigger DHCP renew.
>

I probably don't follow: why do we need sucha a delay? If (with real
hardware) you plug network cable out and in one second you plug it in
you'll get DHCP renewed, right?

When I introduced RNDIS_STATUS_NETWORK_CHANGE handling by emulating a
pair of up/down events I put 2 second delay to make link_watch happy (as
we only handle 1 event per second there) but 10 seconds sounds to much
to me.

> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
>  drivers/net/hyperv/netvsc_drv.c |   10 ++++++++--
>  1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 1d3a665..6f23973 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -43,6 +43,8 @@
>
>  #define RING_SIZE_MIN 64
>  #define LINKCHANGE_INT (2 * HZ)
> +/* Extra delay for RNDIS_STATUS_NETWORK_CHANGE: */
> +#define LINKCHANGE_DELAY (8 * HZ)
>  static int ring_size = 128;
>  module_param(ring_size, int, S_IRUGO);
>  MODULE_PARM_DESC(ring_size, "Ring buffer size (# of pages)");
> @@ -964,6 +966,7 @@ static void netvsc_link_change(struct work_struct *w)
>  		return;
>  	}
>  	ndev_ctx->last_reconfig = jiffies;
> +	delay = LINKCHANGE_INT;
>
>  	spin_lock_irqsave(&ndev_ctx->lock, flags);
>  	if (!list_empty(&ndev_ctx->reconfig_events)) {
> @@ -1009,8 +1012,11 @@ static void netvsc_link_change(struct work_struct *w)
>  			netif_tx_stop_all_queues(net);
>  			event->event = RNDIS_STATUS_MEDIA_CONNECT;
>  			spin_lock_irqsave(&ndev_ctx->lock, flags);
> -			list_add_tail(&event->list, &ndev_ctx->reconfig_events);
> +			list_add(&event->list, &ndev_ctx->reconfig_events);

Why? Adding to tail was here to not screw the order of events...

>  			spin_unlock_irqrestore(&ndev_ctx->lock, flags);
> +
> +			ndev_ctx->last_reconfig += LINKCHANGE_DELAY;
> +			delay = LINKCHANGE_INT + LINKCHANGE_DELAY;
>  			reschedule = true;
>  		}
>  		break;
> @@ -1025,7 +1031,7 @@ static void netvsc_link_change(struct work_struct *w)
>  	 * second, handle next reconfig event in 2 seconds.
>  	 */
>  	if (reschedule)
> -		schedule_delayed_work(&ndev_ctx->dwork, LINKCHANGE_INT);
> +		schedule_delayed_work(&ndev_ctx->dwork, delay);
>  }
>
>  static void netvsc_free_netdev(struct net_device *netdev)

-- 
  Vitaly

  reply	other threads:[~2016-02-03 13:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03  0:15 [PATCH net-next] hv_netvsc: Increase delay for RNDIS_STATUS_NETWORK_CHANGE Haiyang Zhang
2016-02-03  0:15 ` Haiyang Zhang
2016-02-03 13:05 ` Vitaly Kuznetsov [this message]
2016-02-03 13:05   ` Vitaly Kuznetsov
2016-02-03 15:46   ` Haiyang Zhang
2016-02-03 15:46     ` Haiyang Zhang
2016-02-03 16:06     ` Vitaly Kuznetsov
2016-02-03 16:39       ` Haiyang Zhang
2016-02-03 16:39         ` Haiyang Zhang
2016-02-09 10:04 ` David Miller
2016-02-09 10:04   ` David Miller
2016-02-09 15:31   ` Haiyang Zhang
2016-02-09 15:31     ` Haiyang Zhang
2016-02-16 20:28     ` David Miller
2016-02-17 12:53       ` Vitaly Kuznetsov

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=87si1ax7t9.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=davem@davemloft.net \
    --cc=driverdev-devel@linuxdriverproject.org \
    --cc=haiyangz@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olaf@aepfle.de \
    /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.