Re: [DISCUSS] CEP-49: Hardware-accelerated compression

> > Living in the repo - how would we even run CI? How can the PMC vote to > release code they can’t execute? > This would be a concern for me as well. On the pluggable front, the compaction compression class is already a pluggable interface. Is it worth having a second interface for the accelera

Re: [DISCUSS] CEP-49: Hardware-accelerated compression

Pluggable is a net winLiving 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 wrote:From skimming the CEP (limited on time):We propose a framework which can perform the offload when hardware is available an

Re: [DISCUSS] CEP-49: Hardware-accelerated compression

If it is a plug-in solution, I might think it is a good idea. What Cassandra needs to do is to define the interface (may be based on the need for hardware acceleration). It is not a good idea to add hardware-dependent classes to the Cassandra code. Abe Ratnofsky 于2025年6月6日周五 06:08写道： > I’m als

Re: [DISCUSS] CEP-49: Hardware-accelerated compression

>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

[DISCUSS] CEP-49: Hardware-accelerated compression

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/decompre

Re: [DISCUSS] CEP-49: Hardware-accelerated compression

I’m also supportive of making this behavior pluggable, and starting with an out-of-tree implementation. I do think we need to extend ICompressor to differentiate between compression format and implementation to make this work nicely. A new QatZstdCompressor should be read and write compatible w

Re: [DISCUSS] CEP-49: Hardware-accelerated compression

One perpetual challenge with customizing codebase for  dedicated hardware is ongoing support / testing / maintenance followed by ensuring vendor agnostic / neutral accessQAT 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 acc