All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Zoltan Kiss <zoltan.kiss@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, <ian.campbell@citrix.com>,
	<xen-devel@lists.xenproject.org>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <jonathan.davies@citrix.com>
Subject: Re: [PATCH net-next v4 8/9] xen-netback: Timeout packets in RX path
Date: Mon, 20 Jan 2014 16:53:56 +0000	[thread overview]
Message-ID: <20140120165356.GF11681@zion.uk.xensource.com> (raw)
In-Reply-To: <52D98427.1060103@citrix.com>

On Fri, Jan 17, 2014 at 07:27:35PM +0000, Zoltan Kiss wrote:
> On 16/01/14 00:03, Wei Liu wrote:
> >On Tue, Jan 14, 2014 at 08:39:54PM +0000, Zoltan Kiss wrote:
> >[...]
> >>diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> >>index 109c29f..d1cd8ce 100644
> >>--- a/drivers/net/xen-netback/common.h
> >>+++ b/drivers/net/xen-netback/common.h
> >>@@ -129,6 +129,9 @@ struct xenvif {
> >>  	struct xen_netif_rx_back_ring rx;
> >>  	struct sk_buff_head rx_queue;
> >>  	RING_IDX rx_last_skb_slots;
> >
> >Hmm... You seemed to mix your other patch with this series. :-)
> Yep, this series doesn't work without that patch (actually that is a
> bug in netback even without my series), so at the moment it is based
> on it.
> 
> >
> >>+	bool rx_queue_purge;
> >>+
> >>+	struct timer_list wake_queue;
> >>
> >>  	/* This array is allocated seperately as it is large */
> >>  	struct gnttab_copy *grant_copy_op;
> >>@@ -225,4 +228,7 @@ void xenvif_idx_unmap(struct xenvif *vif, u16 pending_idx);
> >>
> >>  extern bool separate_tx_rx_irq;
> >>
> >[...]
> >>@@ -559,7 +579,7 @@ void xenvif_free(struct xenvif *vif)
> >>  		if (vif->grant_tx_handle[i] != NETBACK_INVALID_HANDLE) {
> >>  			unmap_timeout++;
> >>  			schedule_timeout(msecs_to_jiffies(1000));
> >>-			if (unmap_timeout > 9 &&
> >>+			if (unmap_timeout > ((rx_drain_timeout_msecs/1000) * DIV_ROUND_UP(XENVIF_QUEUE_LENGTH, (XEN_NETIF_RX_RING_SIZE / MAX_SKB_FRAGS))) &&
> >
> >This line is really too long. And what's the rationale behind this long
> >expression?
> It calculates how many times you should ditch the internal queue of
> an another (maybe stucked) vif before Qdisc empties it's actual
> content. After that there shouldn't be any mapped handle left, so we
> should start printing these messages. Actually it should use
> vif->dev->tx_queue_len, and yes, it is probably better to move it to
> the beginning of the function into a new variable, and use that
> here.
> 

Why is relative to tx queue length?

What's the meaning of drain_timeout multipled by the last part
(DIV_ROUND_UP)?

If you proposed to use vif->dev->tx_queue_len to replace DIV_ROUND_UP
then ignore the above question. But I still don't understand the
rationale behind this. Could you elaborate a bit more? Wouldn't
rx_drain_timeout_msecs/1000 along suffice?

Wei.

> Zoli

  parent reply	other threads:[~2014-01-20 16:54 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-14 20:39 [PATCH net-next v4 0/9] xen-netback: TX grant mapping with SKBTX_DEV_ZEROCOPY instead of copy Zoltan Kiss
2014-01-14 20:39 ` [PATCH net-next v4 1/9] xen-netback: Introduce TX grant map definitions Zoltan Kiss
2014-01-14 20:39   ` Zoltan Kiss
2014-01-15 15:16   ` Zoltan Kiss
2014-01-15 15:16   ` Zoltan Kiss
2014-01-16  0:00   ` Wei Liu
2014-01-20 16:53     ` Zoltan Kiss
2014-01-20 16:53     ` Zoltan Kiss
2014-01-16  0:00   ` Wei Liu
2014-01-14 20:39 ` [PATCH net-next v4 2/9] xen-netback: Change TX path from grant copy to mapping Zoltan Kiss
2014-01-16  0:01   ` Wei Liu
2014-01-20 17:04     ` Zoltan Kiss
2014-01-20 17:04     ` Zoltan Kiss
2014-01-16  0:01   ` Wei Liu
2014-01-14 20:39 ` Zoltan Kiss
2014-01-14 20:39 ` [PATCH net-next v4 3/9] xen-netback: Remove old TX grant copy definitons and fix indentations Zoltan Kiss
2014-01-16  0:02   ` Wei Liu
2014-01-16  0:02   ` Wei Liu
2014-01-14 20:39 ` Zoltan Kiss
2014-01-14 20:39 ` [PATCH net-next v4 4/9] xen-netback: Change RX path for mapped SKB fragments Zoltan Kiss
2014-01-14 20:39 ` Zoltan Kiss
2014-01-14 20:39 ` [PATCH net-next v4 5/9] xen-netback: Add stat counters for zerocopy Zoltan Kiss
2014-01-14 20:39 ` Zoltan Kiss
2014-01-14 20:39 ` [PATCH net-next v4 6/9] xen-netback: Handle guests with too many frags Zoltan Kiss
2014-01-16  0:03   ` Wei Liu
2014-01-20 17:26     ` Zoltan Kiss
2014-01-20 17:26     ` Zoltan Kiss
2014-01-16  0:03   ` Wei Liu
2014-01-14 20:39 ` Zoltan Kiss
2014-01-14 20:39 ` [PATCH net-next v4 7/9] xen-netback: Add stat counters for frag_list skbs Zoltan Kiss
2014-01-14 20:39 ` Zoltan Kiss
2014-01-14 20:39 ` [PATCH net-next v4 8/9] xen-netback: Timeout packets in RX path Zoltan Kiss
2014-01-16  0:03   ` Wei Liu
2014-01-17 19:27     ` Zoltan Kiss
2014-01-20 16:53       ` Wei Liu
2014-01-20 16:53       ` Wei Liu [this message]
2014-01-20 17:47         ` Zoltan Kiss
2014-01-20 17:47         ` Zoltan Kiss
2014-01-17 19:27     ` Zoltan Kiss
2014-01-16  0:03   ` Wei Liu
2014-01-14 20:39 ` Zoltan Kiss
2014-01-14 20:39 ` [PATCH net-next v4 9/9] xen-netback: Aggregate TX unmap operations Zoltan Kiss
2014-01-14 20:39 ` Zoltan Kiss

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=20140120165356.GF11681@zion.uk.xensource.com \
    --to=wei.liu2@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=jonathan.davies@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=zoltan.kiss@citrix.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.