Shylaja, thanks for your proposal and messages on this thread. I share Jeff's questions and have a couple more. I appreciate that
there is a software fallback, but want to ensure that members of the development community are able to test this feature; and to
understand Intel's long-term commitment to evolving and maintaining a vendor- and model-specific codec family in Apache Cassandra. –
The CEP includes a section labeled "Setup used to generate results above", but I don't see a summary of results, graphs, or
benchmark details. Could you point me to them or upload to the Confluence wiki? – How could the Apache Cassandra project exercise
this feature with acceleration in our CI? I doubt our current hardware supports this feature, which would make it untestable as part
of the project's release process if so. – Are there cloud providers that support it; and if so who and which instance types? I see
that AWS offers QAT in the r7i instance family – but only for "metal" instances which are much more expensive and uncommon
to use: https://aws.amazon.com/ec2/instance-types/r7i/ . – Outside of cloud providers, how does one determine if a given processor
supports QAT (i.e., a specific list of chips)? I've tried browsing the QAT website but the PDFs don't seem to contain this
information, and I don't see QAT as a filterable attribute on ark.apple.com. – Is there a member of the Cassandra community (or Intel
directly) who commits to run the database in a production capacity using one or more QAT codecs? – Can you describe Intel's
commitment to long-term maintenance/support of this feature? I'd feel more comfortable with this proposal in-tree if it were to take
advantage of a standard and widely-available instruction set or extension (like AES-NI, AVX, or NEON). But if it requires specific
chip models or a dedicated PCIe card, metal-only cloud instances, and a custom Linux driver to enable, it would seem most appropriate
for the feature to live out of tree but possible for users of QAT to enable via adding the jar to their classpath. – Scott On Jun 9,
2025, at 3:13 PM, "Kokoori, Shylaja" <shylaja.koko...@intel.com> wrote: Hi Jeff, Thank you very much for your
response. I understand your concern. Here are some details, hope it helps. Customers have access to Intel Product SKUs with or
without Intel® QAT. Our SW Architecture abstracts the use of the Intel® QAT Hardware such that if it is not present on a given Intel
CPU, or the Customer is using a competitive Intel Architecture CPU, the QATZip Library shown below can call the SW Compression
Library instead of calling for a Hardware response of the Intel® QAT Accelerator. Therefore customers can use the same SW
architecture whether or not the HW accelerator is present. <image001.png> See the following Technical Paper on using Intel® QAT
and the QATZip Library. This paper discusses why QATzip exists, its applications, value for developers, and reviews the performance
gains. Intel® QuickAssist Technology - Deliver Compression Efficiencies in the Cloud with Intel® QAT and QATzip Solution Brief Thank
you, Shylaja From: Jeff Jirsa <jji...@gmail.com> Sent: Thursday, June 05, 2025 12:13 PM To: dev@cassandra.apache.org Cc:
dev@cassandra.apache.org Subject: 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 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
