> > 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 <jji...@gmail.com> 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 <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 > <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 > > > > >
