Hi Stefan, Thank you very much for the feedback. You are correct, QAT is available on-die and not hot-plugged, and under normal circumstances , we shouldn't encounter this exception. However, wanted to add reverting to base compressor to make it fault-tolerant.
While the QAT software stack includes built-in retries and software fallbacks for scenarios when devices end up being busy etc., I didn't want operations to fail due to transient hardware issues which otherwise would have succeeded. An example would be, some unrecoverable error occurring during a compress/decompress operation—whether due to a hardware issue or caused by related software libraries—the system can gracefully revert to the base compressor rather than failing the operation entirely. I am open to other suggestions. Thanks, Shylaja ________________________________ From: Štefan Miklošovič <[email protected]> Sent: Monday, December 15, 2025 2:50 PM To: [email protected] <[email protected]> Subject: Re: [VOTE] CEP-49: Hardware-accelerated compression Hi Shylaja, I am going through CEP so I can make the decision when voting and I want to clarify a few things. You say there: Both the default compressor instance and a plugin compressor instance (obtained from the provider), will be maintained by Cassandra. For subsequent read/write operations, the plugin compressor will be used. However, if the plugin version encounters an error, the default compressor will handle the operation. Why are we doing this kind of "fallback"? Under what circumstances "the plugin version encounters an error"? Why would it? It might be understandable to do it like that if that compression accelerator would be some "plug and play" or we could just remove it from a running machine. But this does not seem to be the case? QAT you are mentioning is baked into the CPU, right? It is not like we would decide to just turn it suddenly off in runtime so the database would need to deal with it. The reason I am asking is that I just briefly went over the PR and the way it works there is that if plugin de/compression is not possible (it throws IOException) then it will default to a software solution. This is done for every single de/compression of a chunk. Is this design the absolute must? On Mon, Dec 15, 2025 at 8:14 PM Josh McKenzie <[email protected]> wrote: > > Yes but it's in reply to the discussion thread and so it threads that way in > clients > > Apparently not in fastmail's client because it shows up as its own thread for > me. /sigh > > Hence the confusion. Makes sense now. > > On Mon, Dec 15, 2025, at 1:18 PM, Kokoori, Shylaja wrote: > > Thank you for your feedback, Patrick & Brandon. I have created a new email > thread like you suggested. Hopefully, this works. > > -Shylaja > > ________________________________ > From: Patrick McFadin <[email protected]> > Sent: Monday, December 15, 2025 9:26 AM > To: [email protected] <[email protected]> > Subject: Re: [VOTE] CEP-49: Hardware-accelerated compression > > That was my point. It's a [DISCUSS] thread. > > On Mon, Dec 15, 2025 at 9:22 AM Brandon Williams <[email protected]> wrote: > > On Mon, Dec 15, 2025 at 11:13 AM Josh McKenzie <[email protected]> wrote: > > > > Can you put this into a [VOTE] thread? > > > > I'm confused - isn't the subject of this email [VOTE]? > > Yes but it's in reply to the discussion thread and so it threads that > way in clients, making it easy to overlook. > > Kind Regards, > Brandon > >
