[
https://issues.apache.org/jira/browse/CASSANDRA-16360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17334647#comment-17334647
]
Sam Tunnicliffe commented on CASSANDRA-16360:
---------------------------------------------
Thanks [~benedict]. [~azotcsit], one other thing I wanted to mention is that
your plan to move forward includes changes to both the internode and client
protocols. While these two subsystems do share code, in particular the Frame
encoder/decoders, it's not necessary to evolve the two protocols in lockstep.
If you implement step 7 so that the encoders/decoders support both CRC32 and
CRC32C then this becomes two separate (possibly parallelisable) pieces of work.
I would highly recommend approaching it in this way as either piece is a
significant effort, the client/server protocol probably more so as it involves
coordination with the various client implementations to ensure compatibility.
> CRC32 is inefficient on x86
> ---------------------------
>
> Key: CASSANDRA-16360
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16360
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
> Reporter: Avi Kivity
> Assignee: Alexey Zotov
> Priority: Normal
> Labels: protocolv6
> Fix For: 4.0.x
>
>
> The client/server protocol specifies CRC24 and CRC32 as the checksum
> algorithm (cql_protocol_V5_framing.asc). Those however are expensive to
> compute; this affects both the client and the server.
>
> A better checksum algorithm is CRC32C, which has hardware support on x86 (as
> well as other modern architectures).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
