Hi Randy,
shouldn't be the right fix "for now" that we do not
offload SCTP checksum computation for IPv6?
The point is the semantic of the CSUM_SCTP flag. I think
it means "will csum SCTP for IPv4" as all the other
flags (CSUM_TCP, CSUM_UDP).
With "for now" I mean "until there is a IPv6 checksum
Hmm... M_PROTO* good idea ;-)
On Mar 13, 2010, at 10:56 PM, Bruce Simpson wrote:
On 03/13/10 13:53, Robert N. M. Watson wrote:
On Mar 13, 2010, at 1:50 PM, Randall Stewart wrote:
I could refactor that this way if you want... it would mean a few
more de-ref's and
looking to see if its a v4
On 03/13/10 13:53, Robert N. M. Watson wrote:
On Mar 13, 2010, at 1:50 PM, Randall Stewart wrote:
I could refactor that this way if you want... it would mean a few more de-ref's
and
looking to see if its a v4 or v6 packet and then doing the proper offset...
This is the sort of thing
On Mar 13, 2010, at 1:50 PM, Randall Stewart wrote:
> did not think of that.. we COULD possible do it another way.. a bit harder
> but possible.. i.e. have the delayed sack code actually look into
> the mbufs and see if its ipv4 or ipv6.. I thought about doing it
> that way but it takes more cycl
Hmm.
did not think of that.. we COULD possible do it another way.. a bit
harder
but possible.. i.e. have the delayed sack code actually look into
the mbufs and see if its ipv4 or ipv6.. I thought about doing it
that way but it takes more cycles ;-o
I could refactor that this way if you want..
On Fri, 12 Mar 2010, Randall Stewart wrote:
The proper fix for the delayed SCTP checksum is to
have the delayed function take an argument as to the offset
to the SCTP header. This allows it to work for V4 and V6.
This of course means changing all callers of the function
to either pass the
