[ovs-dev] [PATCH 2/4] dpif-netdev: Add SCTP support

Joe Stringer joe at wand.net.nz
Mon Oct 1 11:44:53 UTC 2012


On 28 September 2012 04:53, Ben Pfaff <blp at nicira.com> wrote:
> "sparse" reports a potential byte-swapping error:

I would imagine this is because the CRC32C implementation I introduced
in patch #1 purports to calculate checksums in HBO. Perhaps that
should be modified to use ovs_be32?

> It looks to me like the SCTP checksum is getting computed across the
> entire packet, including the Ethernet header.  I doubt that that can
> be correct.  Can you take a look?

I wasn't 100% confident that I understood how the function was
interacting with the ofpbuf struct, so it's likely I've simply got it
wrong. With a fresh look it seems like I should actually be using *sh
to calculate the checksum. I'll make the modification for round two.

> Also, for IP-like checksums we're able to do an incremental update of
> the checksum, instead of a wholesale replacement, which means that any
> error in the original checksum will be retained, so that the packet
> will (correctly) be discarded when it arrives at its destination.  To
> preserve that property, I think we'd have to check the checksum before
> we update it.  We could do something like this:
>
> ...
>
> so that the behavior is quite similar to that for TCP and UDP,
> although much more expensive.

I see. I wasn't sure if CRC32c was IP-like enough (no reason, I just
haven't studied the CRCs). I also misinterpreted the reasoning for
updating the checksum.

Do we currently have code that triggers this? I take it that this type
of recalculation is required when we modify the packet, eg set-field
action. What I'd like to know is how I might test that the behaviour
is correct.

One idea perhaps would be to place OVS between two hosts and make it
change the destination port on flows in one direction, then using
lksctp, see whether the hosts continue to communicate correctly. This
has been my general approach to testing this patchset. The downside is
that it's a lot of overhead to set up, unlike the autotests.



More information about the dev mailing list