[ovs-dev] [PATCH] datapath: Consistently maintain checksum offloading state.

Jesse Gross jesse at nicira.com
Mon Mar 1 18:42:19 UTC 2010


On Mon, Mar 1, 2010 at 12:59 PM, Ben Pfaff <blp at nicira.com> wrote:

> On Sun, Feb 28, 2010 at 04:01:42PM -0500, Jesse Gross wrote:
> > When adding a VLAN tag it is necessary for us to setup checksum
> > pointers for offloaded packets manually.  However, this process
> > clobbers some of the fields that other components need to determine
> > the current status.  Here we mark the packet with its status upon
> > ingress in our own format that does not get clobbered and is
> > consistent across kernel versions.
>
> What gets clobbered?  What you say makes sense, but I don't see where it
> happens, or to what.
>

On Xen 5.5 we need to distinguish between CHECKSUM_PARTIAL and
CHECKSUM_COMPLETE since both can occur and both map to CHECKSUM_HW.
 Normally we can use skb->proto_csum_blank, which was added for this
purpose.  However, when adding a vlan tag we need to call
skb_checksum_setup, which clears proto_csum_blank.  That usually isn't an
issue because it is typically called on the transmit path, so there is no
ambiguity between the two types of checksums. We run into issues because we
are sitting in the middle of the receive and transmit paths.


>
> > @@ -606,7 +609,7 @@ int vswitch_skb_checksum_setup(struct sk_buff *skb)
> >       if (skb->protocol != htons(ETH_P_IP))
> >               goto out;
> >
> > -     if (!skb_pull_up_to(skb, skb_network_header(skb) + 1))
> > +     if (!skb_pull_up_to(skb, skb_network_header(skb) + sizeof(struct
> iphdr)))
> >               goto out;
> >
> >       iph = ip_hdr(skb);
>
> The above change looks like an important fix in its own right.  How much
> of the problem was actually in that one line?
>

None actually.  Xen always copies the packet headers into the linear data
buffer of the skb so the guest can't twiddle with them to send a packet
where it shouldn't.  This line was definitely wrong before but in practice
it always returns true without changing anything.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100301/6403c7c4/attachment-0003.html>


More information about the dev mailing list