pvops: update the SKB slots patch (#560)

devel-3.9 mm_0ebad766
Marek Marczykowski 12 years ago
parent e929164e52
commit 0ebad7661f

@ -1,60 +1,42 @@
Subject: [Xen-devel] [PATCH] xen/netback: calculate correctly the SKB slots.
Date: Mon, 21 May 2012 13:36:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
netdev@vger.kernel.org, davem@davemloft.net, linux-kernel@vger.kernel.org
CC: Adnan Misherfi <adnan.misherfi@oracle.com>, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>
From: Adnan Misherfi <adnan.misherfi@oracle.com>
A programming error cause the calculation of receive SKB slots to be
wrong, which caused the RX ring to be erroneously declared full,
and the receive queue to be stopped. The problem shows up when two
guest running on the same server tries to communicates using large
MTUs. Each guest is connected to a bridge with VLAN over bond
interface, so traffic from one guest leaves the server on one bridge
and comes back to the second guest on the second bridge. This can be
reproduces using ping, and one guest as follow:
- Create active-back bond (bond0)
- Set up VLAN 5 on bond0 (bond0.5)
- Create a bridge (br1)
- Add bond0.5 to a bridge (br1)
- Start a guest and connect it to br1
- Set MTU of 9000 across the link
Ping the guest from an external host using packet sizes of 3991, and
4054; ping -s 3991 -c 128 "Guest-IP-Address"
At the beginning ping works fine, but after a while ping packets do
not reach the guest because the RX ring becomes full, and the queue
get stopped. Once the problem accrued, the only way to get out of it
is to reboot the guest, or use xm network-detach/network-attach.
ping works for packets sizes 3990,3992, and many other sizes including
4000,5000,9000, and 1500 ..etc. MTU size of 3991,4054 are the sizes
that quickly reproduce this problem.
Signed-off-by: Adnan Misherfi <adnan.misherfi@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
From: Simon Graham <simon.graham@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "konrad.wilk@oracle.com"
<konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "netdev@vger.kernel.org"
<netdev@vger.kernel.org>
Date: Thu, 24 May 2012 12:26:07 -0400
Cc: "bhutchings@solarflare.com" <bhutchings@solarflare.com>,
Simon Graham <simon.graham@citrix.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"adnan.misherfi@oracle.com" <adnan.misherfi@oracle.com>
Subject: [Xen-devel] [PATCH] xen/netback: Calculate the number of SKB slots
required correctly
When calculating the number of slots required for a packet header, the code
was reserving too many slots if the header crossed a page boundary. Since
netbk_gop_skb copies the header to the start of the page, the count of
slots required for the header should be based solely on the header size.
This problem is easy to reproduce if a VIF is bridged to a USB 3G modem
device as the skb->data value always starts near the end of the first page.
Signed-off-by: Simon Graham <simon.graham@citrix.com>
---
drivers/net/xen-netback/netback.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
drivers/net/xen-netback/netback.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 957cf9d..e382e5b 100644
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2596401..f4a6fca 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -212,7 +212,7 @@ unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
@@ -325,8 +325,7 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
unsigned int count;
int i, copy_off;
count = DIV_ROUND_UP(
- count = DIV_ROUND_UP(
- offset_in_page(skb->data)+skb_headlen(skb), PAGE_SIZE);
+ offset_in_page(skb->data + skb_headlen(skb)), PAGE_SIZE);
+ count = DIV_ROUND_UP(skb_headlen(skb), PAGE_SIZE);
copy_off = skb_headlen(skb) % PAGE_SIZE;
--
1.7.7.5
1.7.9.1

Loading…
Cancel
Save