All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Carsten Otte <cotte@de.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	linux390@de.ibm.com, Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Shirley Ma <xma@us.ibm.com>,
	lguest@lists.ozlabs.org,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, linux-s390@vger.kernel.org,
	kvm@vger.kernel.org, Krishna Kumar <krkumar2@in.ibm.com>,
	Tom Lendacky <tahm@linux.vnet.ibm.com>,
	steved@us.ibm.com, habanero@linux.vnet.ibm.com
Subject: Re: [PATCHv2 RFC 3/4] virtio_net: limit xmit polling
Date: Tue, 7 Jun 2011 18:59:15 +0300	[thread overview]
Message-ID: <20110607155915.GA17581@redhat.com> (raw)
In-Reply-To: <a80199422de16ae355e56ee1b2abc9b2bf91a7f6.1307029009.git.mst@redhat.com>

On Thu, Jun 02, 2011 at 06:43:17PM +0300, Michael S. Tsirkin wrote:
> Current code might introduce a lot of latency variation
> if there are many pending bufs at the time we
> attempt to transmit a new one. This is bad for
> real-time applications and can't be good for TCP either.
> 
> Free up just enough to both clean up all buffers
> eventually and to be able to xmit the next packet.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


I've been testing this patch and it seems to work fine
so far. The following fixups are needed to make it
build though:


diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b25db1c..77cdf34 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -529,11 +529,8 @@ static bool free_old_xmit_skb(struct virtnet_info *vi)
  * virtqueue_add_buf will succeed. */
 static bool free_xmit_capacity(struct virtnet_info *vi)
 {
-	struct sk_buff *skb;
-	unsigned int len;
-
 	while (virtqueue_min_capacity(vi->svq) < MAX_SKB_FRAGS + 2)
-		if (unlikely(!free_old_xmit_skb))
+		if (unlikely(!free_old_xmit_skb(vi)))
 			return false;
 	return true;
 }
@@ -628,7 +625,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
 	 * Doing this after kick means there's a chance we'll free
 	 * the skb we have just sent, which is hot in cache. */
 	for (i = 0; i < 2; i++)
-		free_old_xmit_skb(v);
+		free_old_xmit_skb(vi);
 
 	if (likely(free_xmit_capacity(vi)))
 		return NETDEV_TX_OK;

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Krishna Kumar <krkumar2-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org>,
	Carsten Otte <cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>,
	lguest-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	Shirley Ma <xma-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
	Heiko Carstens
	<heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	steved-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org,
	Christian Borntraeger
	<borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>,
	Tom Lendacky
	<tahm-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
	Martin Schwidefsky
	<schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>,
	linux390-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCHv2 RFC 3/4] virtio_net: limit xmit polling
Date: Tue, 7 Jun 2011 18:59:15 +0300	[thread overview]
Message-ID: <20110607155915.GA17581@redhat.com> (raw)
In-Reply-To: <a80199422de16ae355e56ee1b2abc9b2bf91a7f6.1307029009.git.mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Thu, Jun 02, 2011 at 06:43:17PM +0300, Michael S. Tsirkin wrote:
> Current code might introduce a lot of latency variation
> if there are many pending bufs at the time we
> attempt to transmit a new one. This is bad for
> real-time applications and can't be good for TCP either.
> 
> Free up just enough to both clean up all buffers
> eventually and to be able to xmit the next packet.
> 
> Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>


I've been testing this patch and it seems to work fine
so far. The following fixups are needed to make it
build though:


diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b25db1c..77cdf34 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -529,11 +529,8 @@ static bool free_old_xmit_skb(struct virtnet_info *vi)
  * virtqueue_add_buf will succeed. */
 static bool free_xmit_capacity(struct virtnet_info *vi)
 {
-	struct sk_buff *skb;
-	unsigned int len;
-
 	while (virtqueue_min_capacity(vi->svq) < MAX_SKB_FRAGS + 2)
-		if (unlikely(!free_old_xmit_skb))
+		if (unlikely(!free_old_xmit_skb(vi)))
 			return false;
 	return true;
 }
@@ -628,7 +625,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
 	 * Doing this after kick means there's a chance we'll free
 	 * the skb we have just sent, which is hot in cache. */
 	for (i = 0; i < 2; i++)
-		free_old_xmit_skb(v);
+		free_old_xmit_skb(vi);
 
 	if (likely(free_xmit_capacity(vi)))
 		return NETDEV_TX_OK;

  parent reply	other threads:[~2011-06-07 15:59 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-02 15:42 [PATCHv2 RFC 0/4] virtio and vhost-net capacity handling Michael S. Tsirkin
2011-06-02 15:42 ` Michael S. Tsirkin
2011-06-02 15:42 ` [PATCHv2 RFC 1/4] virtio_ring: add capacity check API Michael S. Tsirkin
2011-06-02 15:42 ` Michael S. Tsirkin
2011-06-02 15:42   ` Michael S. Tsirkin
2011-06-02 15:43 ` [PATCHv2 RFC 2/4] virtio_net: fix tx capacity checks using new API Michael S. Tsirkin
2011-06-02 15:43 ` Michael S. Tsirkin
2011-06-02 15:43   ` Michael S. Tsirkin
2011-06-02 15:43 ` [PATCHv2 RFC 3/4] virtio_net: limit xmit polling Michael S. Tsirkin
2011-06-02 15:43   ` Michael S. Tsirkin
2011-06-02 18:09   ` Sridhar Samudrala
2011-06-02 18:09   ` Sridhar Samudrala
2011-06-02 19:23     ` Michael S. Tsirkin
2011-06-02 19:23     ` Michael S. Tsirkin
2011-06-02 19:23       ` Michael S. Tsirkin
2011-06-07 15:59   ` Michael S. Tsirkin
2011-06-07 15:59   ` Michael S. Tsirkin [this message]
2011-06-07 15:59     ` Michael S. Tsirkin
2011-06-02 15:43 ` Michael S. Tsirkin
2011-06-02 15:43 ` [PATCHv2 RFC 4/4] Revert "virtio: make add_buf return capacity remaining: Michael S. Tsirkin
2011-06-02 15:43 ` Michael S. Tsirkin
2011-06-02 15:43   ` Michael S. Tsirkin
2011-06-07 15:54   ` Michael S. Tsirkin
2011-06-07 15:54     ` Michael S. Tsirkin
2011-06-08  0:19     ` Rusty Russell
2011-06-08  0:19     ` Rusty Russell
2011-06-07 15:54   ` Michael S. Tsirkin
2011-06-02 17:17 ` [PATCHv2 RFC 0/4] virtio and vhost-net capacity handling Michael S. Tsirkin
2011-06-02 17:17 ` Michael S. Tsirkin
2011-06-02 17:17   ` Michael S. Tsirkin
2011-06-06  3:39   ` Rusty Russell
2011-06-06  3:39     ` Rusty Russell
2011-06-06  3:39   ` Rusty Russell
2011-06-07 16:08 ` Michael S. Tsirkin
2011-06-07 16:08   ` Michael S. Tsirkin
2011-06-13 13:32   ` Krishna Kumar2
2011-06-13 13:32   ` Krishna Kumar2
2011-06-13 13:35     ` Michael S. Tsirkin
2011-06-13 13:35     ` Michael S. Tsirkin
2011-06-13 13:35       ` Michael S. Tsirkin
2011-06-13 13:44       ` Krishna Kumar2
2011-06-13 13:44         ` Krishna Kumar2
2011-06-13 13:44       ` Krishna Kumar2
2011-06-13 13:38     ` Krishna Kumar2
2011-06-13 13:38     ` Krishna Kumar2
2011-06-13 13:38       ` Krishna Kumar2
2011-06-19  8:53     ` Michael S. Tsirkin
2011-06-19  8:53     ` Michael S. Tsirkin
2011-06-19  8:53       ` Michael S. Tsirkin
2011-06-07 16:08 ` Michael S. Tsirkin

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=20110607155915.GA17581@redhat.com \
    --to=mst@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cotte@de.ibm.com \
    --cc=habanero@linux.vnet.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=krkumar2@in.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=lguest@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux390@de.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=schwidefsky@de.ibm.com \
    --cc=steved@us.ibm.com \
    --cc=tahm@linux.vnet.ibm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xma@us.ibm.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.