[ovs-discuss] discuss Digest, Vol 30, Issue 5

Jesse Gross jesse at nicira.com
Fri Dec 16 02:57:05 UTC 2011


2011/12/15 likunyun <kunyunli at hotmail.com>:
>> The URL that you provided requires a username and password to login.
> The account is owned by my company, Maybe I could send the code after I was
> allowed taking the code home, it will take serveral days.
> Or you figure out the information you care, then I provide them.
>
> OVS finish the skb_checksum_setup as soon as it gets packetes in kernel.
> netdev_port_receive() ->compute_ip_summed() ->vswitch_skb_checksum_setup()
> The skb->csum is setted to be csum_offset in vswitch_skb_checksum_setup().
> After the flow being created, the skb->csum wouldn't be corrected in
> kernel except ovs finish the tso .
>
> Why it set the wrong date in sk_buff in the compatibility code for older
> kernels ?

Older versions of Linux did not distinguish between checksums that
have been verified in hardware on  receive and those that need to be
computed in hardware on transmit.  The meanings of these two are very
different but it's generally not ambiguous because you know whether
you are on the transmit or receive path.  The exception to this is
bridging and so Xen added some new fields to disambiguate between
them.  Linux later added fields for the same purpose but different
from the ones that Xen added.  OVS attempts to use the correct ones
depending on the situation.

Your kernel is apparently defining both but is using the Linux model.
Other Xen patched modern kernels with both generally use the Xen
version, so that's what OVS is trying to do.  The question that needs
to be answered is whether the proto_data_valid and proto_csum_blank
fields in struct sk_buff are actually used anywhere or are just
defined (those are Xen's checksum fields).  If the answer is that
they're not used then we need to come up with a test that excludes
your kernel but catches the others.



More information about the discuss mailing list