>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 >> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-49%3A+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 >>
