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

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;
 }
-- 
1.7.4.1


  reply	other threads:[~2015-03-11 17:48 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   ` K. Y. Srinivasan [this message]
2015-03-12  3:07     ` [PATCH V2 2/3 net-next] Drivers: hv: vmbus: Fix a bug in the signalling logic with kick_q Jason Wang
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=1426100660-9547-2-git-send-email-kys@microsoft.com \
    --to=kys@microsoft.com \
    --cc=apw@canonical.com \
    --cc=davem@davemloft.net \
    --cc=devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jasowang@redhat.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