[PATCH] datapath: adjust skb_gso_segment() for calling in rx path
Cong Wang
amwang at redhat.com
Wed Feb 6 22:40:36 UTC 2013
skb_gso_segment() is almost always called in tx path,
except for openvswitch. It calls this function when
it receives the packet and tries to queue it to user-space.
In this special case, the ->ip_summed check inside
skb_gso_segment() is no longer true, as ->ip_summed value
has different meanings on rx path.
This patch adjusts skb_gso_segment() so that we can at least
avoid such warnings on checksum.
Cc: Jesse Gross <jesse at nicira.com<mailto:jesse at nicira.com>>
Cc: David S. Miller <davem at davemloft.net<mailto:davem at davemloft.net>>
Signed-off-by: Cong Wang <amwang at redhat.com<mailto:amwang at redhat.com>>
Signed-off-by: David S. Miller <davem at davemloft.net<mailto:davem at davemloft.=
net>>
[jesse: backport to kernels before 3.9 and add to tunnel.c]
Signed-off-by: Jesse Gross <jesse at nicira.com<mailto:jesse at nicira.com>>
---
...
diff --git a/datapath/tunnel.c b/datapath/tunnel.c
index 6193891..7c2560f 100644
--- a/datapath/tunnel.c
+++ b/datapath/tunnel.c
@@ -435,7 +435,7 @@ static struct sk_buff *handle_offloads(struct sk_buff *=
skb,
if (skb_is_gso(skb)) {
struct sk_buff *nskb;
- nskb =3D skb_gso_segment(skb, 0);
+ nskb =3D __skb_gso_segment(skb, 0, false);
if (IS_ERR(nskb)) {
kfree_skb(skb);
err =3D PTR_ERR(nskb);
--
1.7.9.5
What is the logic of using bool tx_path =3D false on this call in tunnel.c,=
as this is called on ovs_tnl_send() which is on the tx path?
Is it so that this avoids the (skb->ip_summed !=3D CHECKSUM_PARTIAL) compar=
ison that leads to skb_warn_bad_offload(skb)?
If this is the case, how likely is the new comparison (skb->ip_summed =3D=
=3D CHECKSUM_NONE) in Linux 3.9 to resolve the problem with these warnings?
We have a case in which an OpenStack (grizzly) controller node is filling t=
he disk with these kernel warnings and it would be nice to have this resolv=
ed. I guess turning off GSO on the nic involved should work as an interim s=
olution, but it would be nice to understand what is going on here.
Jarno
--_000_7DBBC7A22A2D4107A39F2213BCB52D27nsncom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <CA12A7B472D8D8439A10E483FD7BC0E7 at internal.nsn.com>
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
<pre style=3D"color: rgb(0, 0, 0); font-style: normal; font-variant: normal=
; font-weight: normal; letter-spacing: normal; line-height: normal; orphans=
: auto; text-align: start; text-indent: 0px; text-transform: none; widows: =
auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-strok=
e-width: 0px; word-wrap: break-word; white-space: pre-wrap;"></pre>
<blockquote type=3D"cite">
<pre style=3D"color: rgb(0, 0, 0); font-style: normal; font-variant: normal=
; font-weight: normal; letter-spacing: normal; line-height: normal; orphans=
: auto; text-align: start; text-indent: 0px; text-transform: none; widows: =
auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-strok=
e-width: 0px; word-wrap: break-word; white-space: pre-wrap;">From 0aa52d88b=
df6bc22fed80beb175a6dfe420dfabd Mon Sep 17 00:00:00 2001
From: Cong Wang <<a href=3D"mailto:amwang at redhat.com">amwang at redhat.com<=
/a>>
Date: Wed, 6 Feb 2013 14:40:36 -0800
Subject: [PATCH] datapath: adjust skb_gso_segment() for calling in rx path
skb_gso_segment() is almost always called in tx path,
except for openvswitch. It calls this function when
it receives the packet and tries to queue it to user-space.
In this special case, the ->ip_summed check inside
skb_gso_segment() is no longer true, as ->ip_summed value
has different meanings on rx path.
This patch adjusts skb_gso_segment() so that we can at least
avoid such warnings on checksum.
Cc: Jesse Gross <<a href=3D"mailto:jesse at nicira.com">jesse at nicira.com</a=
>>
Cc: David S. Miller <<a href=3D"mailto:davem at davemloft.net">davem at daveml=
oft.net</a>>
Signed-off-by: Cong Wang <<a href=3D"mailto:amwang at redhat.com">amwang at re=
dhat.com</a>>
Signed-off-by: David S. Miller <<a href=3D"mailto:davem at davemloft.net">d=
avem at davemloft.net</a>>
[jesse: backport to kernels before 3.9 and add to tunnel.c]
Signed-off-by: Jesse Gross <<a href=3D"mailto:jesse at nicira.com">jesse at ni=
cira.com</a>>
---
</pre>
</blockquote>
...<br>
<blockquote type=3D"cite">
<pre style=3D"color: rgb(0, 0, 0); font-style: normal; font-variant: normal=
; font-weight: normal; letter-spacing: normal; line-height: normal; orphans=
: auto; text-align: start; text-indent: 0px; text-transform: none; widows: =
auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-strok=
e-width: 0px; word-wrap: break-word; white-space: pre-wrap;">diff --git a/d=
atapath/tunnel.c b/datapath/tunnel.c
index 6193891..7c2560f 100644
--- a/datapath/tunnel.c
+++ b/datapath/tunnel.c
@@ -435,7 +435,7 @@ static struct sk_buff *handle_offloads(struct sk_bu=
ff *skb,
if (skb_is_gso(skb)) {
struct sk_buff *nskb;
=20
- nskb =3D skb_gso_segment(skb, 0);
+ nskb =3D __skb_gso_segment(skb, 0, false);
if (IS_ERR(nskb)) {
kfree_skb(skb);
err =3D PTR_ERR(nskb);
--=20
1.7.9.5
</pre>
</blockquote>
<div><br>
</div>
<div>What is the logic of using bool tx_path =3D false on this call in tunn=
el.c, as this is called on ovs_tnl_send() which is on the tx path?</div>
<div><br>
</div>
<div>Is it so that this avoids the (skb->ip_summed !=3D CHECKSUM_PA=
RTIAL) comparison that leads to skb_warn_bad_offload(skb)?</div>
<br>
If this is the case, how likely is the new comparison (skb->ip_summed =
=3D=3D CHECKSUM_NONE) in Linux 3.9 to resolve the problem with these w=
arnings?
<div><br>
</div>
<div>
<div>We have a case in which an OpenStack (grizzly) controller node is fill=
ing the disk with these kernel warnings and it would be nice to have this r=
esolved. I guess turning off GSO on the nic involved should work as an inte=
rim solution, but it would be nice
to understand what is going on here.</div>
</div>
<div><br>
</div>
<div> Jarno</div>
<div><br>
</div>
</body>
</html>
--_000_7DBBC7A22A2D4107A39F2213BCB52D27nsncom_--
More information about the dev
mailing list