netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zoltan Kiss <zoltan.kiss@citrix.com>
To: <xen-devel@lists.xenproject.org>, <ian.campbell@citrix.com>,
	<wei.liu2@citrix.com>, <paul.durrant@citrix.com>,
	<linux@eikelenboom.it>, <davem@davemloft.net>
Cc: <netdev@vger.kernel.org>, <david.vrabel@citrix.com>
Subject: Re: [PATCH net] xen-netback: Fix handling of skbs requiring too many slots
Date: Wed, 11 Jun 2014 13:36:40 +0100	[thread overview]
Message-ID: <53984D58.7010708@citrix.com> (raw)
In-Reply-To: <1401827406-9341-1-git-send-email-zoltan.kiss@citrix.com>

Hi,

This patch have made the net and net-next trees already, but not the 
mainline 3.15. That's unfortunate, because just 2 days after someone 
already spotted the problem (see "netback oops in Linux 3.14 / 3.15" on 
xen-devel)
David, should I resend the patch for stable maintaners to include it in 
the 3.15 stable branch?

Regards,

Zoli

On 03/06/14 21:30, Zoltan Kiss wrote:
> A recent commit (a02eb4 "xen-netback: worse-case estimate in xenvif_rx_action is
> underestimating") capped the slot estimation to MAX_SKB_FRAGS, but that triggers
> the next BUG_ON a few lines down, as the packet consumes more slots than
> estimated.
> This patch introduces full_coalesce on the skb callback buffer, which is used in
> start_new_rx_buffer() to decide whether netback needs coalescing more
> aggresively. By doing that, no packet should need more than
> XEN_NETIF_MAX_TX_SIZE / PAGE_SIZE data slots, as the provided buffers are fully
> utilized.
>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> Cc: Paul Durrant <paul.durrant@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> ---
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 64ab1d1..65fbcd1 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -163,7 +163,10 @@ bool xenvif_rx_ring_slots_available(struct xenvif *vif, int needed)
>    * adding 'size' bytes to a buffer which currently contains 'offset'
>    * bytes.
>    */
> -static bool start_new_rx_buffer(int offset, unsigned long size, int head)
> +static bool start_new_rx_buffer(int offset,
> +				unsigned long size,
> +				int head,
> +				bool full_coalesce)
>   {
>   	/* simple case: we have completely filled the current buffer. */
>   	if (offset == MAX_BUFFER_OFFSET)
> @@ -175,6 +178,7 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
>   	 *     (i)   this frag would fit completely in the next buffer
>   	 * and (ii)  there is already some data in the current buffer
>   	 * and (iii) this is not the head buffer.
> +	 * and (iv)  there is no need to fully utilize the buffers
>   	 *
>   	 * Where:
>   	 * - (i) stops us splitting a frag into two copies
> @@ -185,6 +189,8 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
>   	 *   by (ii) but is explicitly checked because
>   	 *   netfront relies on the first buffer being
>   	 *   non-empty and can crash otherwise.
> +	 * - (iv) is needed for skbs which can use up more than MAX_SKB_FRAGS
> +	 *   slot
>   	 *
>   	 * This means we will effectively linearise small
>   	 * frags but do not needlessly split large buffers
> @@ -192,7 +198,10 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
>   	 * own buffers as before.
>   	 */
>   	BUG_ON(size > MAX_BUFFER_OFFSET);
> -	if ((offset + size > MAX_BUFFER_OFFSET) && offset && !head)
> +	if ((offset + size > MAX_BUFFER_OFFSET) &&
> +	    offset &&
> +	    !head &&
> +	    !full_coalesce)
>   		return true;
>
>   	return false;
> @@ -227,6 +236,13 @@ static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
>   	return meta;
>   }
>
> +struct xenvif_rx_cb {
> +	int meta_slots_used;
> +	bool full_coalesce;
> +};
> +
> +#define XENVIF_RX_CB(skb) ((struct xenvif_rx_cb *)(skb)->cb)
> +
>   /*
>    * Set up the grant operations for this fragment. If it's a flipping
>    * interface, we also set up the unmap request from here.
> @@ -261,7 +277,10 @@ static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>   		if (bytes > size)
>   			bytes = size;
>
> -		if (start_new_rx_buffer(npo->copy_off, bytes, *head)) {
> +		if (start_new_rx_buffer(npo->copy_off,
> +					bytes,
> +					*head,
> +					XENVIF_RX_CB(skb)->full_coalesce)) {
>   			/*
>   			 * Netfront requires there to be some data in the head
>   			 * buffer.
> @@ -541,12 +560,6 @@ static void xenvif_add_frag_responses(struct xenvif *vif, int status,
>   	}
>   }
>
> -struct xenvif_rx_cb {
> -	int meta_slots_used;
> -};
> -
> -#define XENVIF_RX_CB(skb) ((struct xenvif_rx_cb *)(skb)->cb)
> -
>   void xenvif_kick_thread(struct xenvif *vif)
>   {
>   	wake_up(&vif->wq);
> @@ -602,10 +615,14 @@ static void xenvif_rx_action(struct xenvif *vif)
>
>   		/* To avoid the estimate becoming too pessimal for some
>   		 * frontends that limit posted rx requests, cap the estimate
> -		 * at MAX_SKB_FRAGS.
> +		 * at MAX_SKB_FRAGS. In this case netback will fully coalesce
> +		 * the skb into the provided slots.
>   		 */
> -		if (max_slots_needed > MAX_SKB_FRAGS)
> +		if (max_slots_needed > MAX_SKB_FRAGS) {
>   			max_slots_needed = MAX_SKB_FRAGS;
> +			XENVIF_RX_CB(skb)->full_coalesce = true;
> +		} else
> +			XENVIF_RX_CB(skb)->full_coalesce = false;
>
>   		/* We may need one more slot for GSO metadata */
>   		if (skb_is_gso(skb) &&
>

  parent reply	other threads:[~2014-06-11 12:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03 20:30 [PATCH net] xen-netback: Fix handling of skbs requiring too many slots Zoltan Kiss
2014-06-04  8:50 ` David Laight
2014-06-04 10:15   ` Zoltan Kiss
2014-06-04 15:53     ` Zoltan Kiss
2014-06-04 15:09 ` annie li
2014-06-04 15:42   ` [Xen-devel] " Zoltan Kiss
2014-06-04 15:59     ` annie li
2014-06-11 12:36 ` Zoltan Kiss [this message]
2014-06-11 19:17   ` David Miller

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=53984D58.7010708@citrix.com \
    --to=zoltan.kiss@citrix.com \
    --cc=davem@davemloft.net \
    --cc=david.vrabel@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=linux@eikelenboom.it \
    --cc=netdev@vger.kernel.org \
    --cc=paul.durrant@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /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;
as well as URLs for NNTP newsgroup(s).