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

[Jeremiah Jordan]

>
> 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
accelerator?  Or should there just be an AcceleratedDeflateCompressor class
available in a plugin jar?  I could go either way.

-Jeremiah

On Jun 5, 2025 at 3:36:15 PM, Jeff Jirsa  wrote:

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

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

[Jeff Jirsa]

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 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 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 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  wrote:Hi everyone, We would like to propose hardware accelerated compression in Cassandra,  CEP-49: Hardware-accelerated compressionAs 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 

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

[guo Maxwell]

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 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 with in-tree
> ZstdCompressor, and a user should be able to enable QatZstdCompressor on a
> single node to evaluate it, without thinking about file compatibility.

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

[Josh McKenzie]

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

[DISCUSS] CEP-49: Hardware-accelerated compression

[Kokoori, Shylaja]

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

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

[Abe Ratnofsky]

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 with in-tree ZstdCompressor, and a user 
should be able to enable QatZstdCompressor on a single node to evaluate it, 
without thinking about file compatibility.

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

[Jeff Jirsa]

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