Pluggable is a net win
Living in the repo - how would we even run CI? How can the PMC vote to release code they can’t execute? On Jun 5, 2025, at 12:37 PM, Josh McKenzie <jmcken...@apache.org> wrote:
From skimming the CEP (limited on time): We propose a framework which can perform the offload when hardware is available and will default to software otherwise. The framework also allows for additional accelerators in the future.
I'm provisionally receptive to this. Not sure whether we'd want the QatCompressor to live inside the C* repo proper vs. having it be a separately ASLv2 licensed repo that users can optionally run. We could link it from the ecosystem on the site for example: https://cassandra.apache.org/_/ecosystem.html.
Introducing an interface here to make this kind of acceleration pluggable seems like it would be a net positive for the ecosystem since there's a lot of compression acceleration options out there.
On Thu, Jun 5, 2025, at 3:12 PM, Jeff Jirsa wrote:
One perpetual challenge with customizing codebase for dedicated hardware is ongoing support / testing / maintenance followed by ensuring vendor agnostic / neutral access
QAT is one of those things that’s great for a set of people paying for it, but I don’t know any current contributors who have access - does anyone not at Intel actually have access to QAT or does intel expect to use this in production yourselves (are you running a cluster where this fix improves your life or are you proposing this as a way to benefit your customers, or both)?
On Jun 5, 2025, at 11:52 AM, Kokoori, Shylaja <shylaja.koko...@intel.com> wrote:
Hi everyone, We would like to propose hardware accelerated compression in Cassandra, CEP-49: Hardware-accelerated compression
As load on Cassandra servers increase, performance of compress/decompress operations starts becoming a bottleneck.
Our goal via this CEP is to offload these operations to dedicated hardware accelerators and free up the CPUs. We'd really appreciate your feedback on this proposal. Thank you, Shylaja
|
