2011/12/15 likunyun <[email protected]>: >> 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. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
