public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
	olaf@aepfle.de, apw@canonical.com, gregkh@linuxfoundation.org,
	"K. Y. Srinivasan" <kys@microsoft.com>
Subject: Re: [PATCH V2 2/3 net-next] Drivers: hv: vmbus: Fix a bug in the signalling logic with kick_q
Date: Thu, 12 Mar 2015 11:07:42 +0800	[thread overview]
Message-ID: <1426129662.12154.2@smtp.corp.redhat.com> (raw)
In-Reply-To: <1426100660-9547-2-git-send-email-kys@microsoft.com>



On Thu, Mar 12, 2015 at 3:04 AM, K. Y. Srinivasan <kys@microsoft.com> 
wrote:
> When the caller specifies that signalling should be deferred, we need 
> to
> address the case where we are not able to place the current packet 
> because
> the buffer is full. In this case, we will signal the host as some 
> packets
> may have been placed on the ring buffer.
> I would like to thank Jason Wang <jasowang@redhat.com> for pointing
> out this issue.
> 
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
>  drivers/hv/channel.c |   32 ++++++++++++++++++++++++++++++++
>  1 files changed, 32 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
> index e58cdb7..ae06ba9 100644
> --- a/drivers/hv/channel.c
> +++ b/drivers/hv/channel.c
> @@ -614,8 +614,24 @@ int vmbus_sendpacket_ctl(struct vmbus_channel 
> *channel, void *buffer,
>  
>  	ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, 
> &signal);
>  
> +	/*
> +	 * Here is the logic for signalling the host:
> +	 * 1. If the host is already draining the ringbuffer,
> +	 *    don't signal. This is indicated by the parameter
> +	 *    "signal".
> +	 *
> +	 * 2. If we are not able to write, signal if kick_q is false.
> +	 *    kick_q being false indicates that we may have placed zero or
> +	 *    more packets with more packets to come. We will signal in
> +	 *    this case even if potentially we may have not placed any
> +	 *    packet. This is a rare enough condition that it should not
> +	 *    matter.
> +	 */
> +
>  	if ((ret == 0) && kick_q && signal)
>  		vmbus_setevent(channel);
> +	else if ((ret != 0) && !kick_q)
> +		vmbus_setevent(channel);
>  
>  	return ret;
>  }
> @@ -705,8 +721,24 @@ int vmbus_sendpacket_pagebuffer_ctl(struct 
> vmbus_channel *channel,
>  
>  	ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, 
> &signal);
>  
> +	/*
> +	 * Here is the logic for signalling the host:
> +	 * 1. If the host is already draining the ringbuffer,
> +	 *    don't signal. This is indicated by the parameter
> +	 *    "signal".
> +	 *
> +	 * 2. If we are not able to write, signal if kick_q is false.
> +	 *    kick_q being false indicates that we may have placed zero or
> +	 *    more packets with more packets to come. We will signal in
> +	 *    this case even if potentially we may have not placed any
> +	 *    packet. This is a rare enough condition that it should not
> +	 *    matter.
> +	 */
> +
>  	if ((ret == 0) && kick_q && signal)
>  		vmbus_setevent(channel);
> +	else if ((ret != 0) && !kick_q)
> +		vmbus_setevent(channel);
>  
>  	return ret;
>  }
> -- 

Looks like we need to kick unconditionally here. Consider we may get 
-EAGAIN when we want to send the last skb (kick_q is true) from the 
list. We need kick host in this case.

Btw, another method is let the driver to decide e.g exporting the 
vmbus_setevent() and call it in netvsc_start_xmit().





  reply	other threads:[~2015-03-12  3:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-11 19:03 [PATCH V2 0/3 net-next] hyperv: Enable batched notification K. Y. Srinivasan
2015-03-11 19:04 ` [PATCH V2 1/3 net-next] Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl() K. Y. Srinivasan
2015-03-11 19:04   ` [PATCH V2 2/3 net-next] Drivers: hv: vmbus: Fix a bug in the signalling logic with kick_q K. Y. Srinivasan
2015-03-12  3:07     ` Jason Wang [this message]
2015-03-12  3:31       ` KY Srinivasan
2015-03-12  4:49         ` KY Srinivasan
2015-03-11 19:04   ` [PATCH V2 3/3 net-next] hyperv: Support batched notification K. Y. Srinivasan
2015-03-12  3:08     ` Jason Wang
2015-03-12  3:33       ` KY Srinivasan
2015-03-12  2:59   ` [PATCH V2 1/3 net-next] Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl() Jason Wang

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=1426129662.12154.2@smtp.corp.redhat.com \
    --to=jasowang@redhat.com \
    --cc=apw@canonical.com \
    --cc=davem@davemloft.net \
    --cc=devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox