Hi Mikulas,
On Wed, Jun 03, 2020 at 04:31:54AM -0400, Mikulas Patocka wrote:
> On Tue, 2 Jun 2020, Giovanni Cabiddu wrote:
> > Hi Mikulas,
> >
> > thanks for your patch. See below.
> >
> > > + qat_req->backed_off = backed_off =
> > > adf_should_back_off(ctx->inst->sym_tx);
> > > +again:
> > > + ret = adf_send_message(ctx->inst->sym_tx, (uint32_t *)msg);
> > > if (ret == -EAGAIN) {
> > > - qat_alg_free_bufl(ctx->inst, qat_req);
> > > - return -EBUSY;
> > > + qat_req->backed_off = backed_off = 1;
> > > + cpu_relax();
> > > + goto again;
> > > }
> > I am a bit concerned about this potential infinite loop.
> > If an error occurred on the device and the queue is full, we will be
> > stuck here forever.
> > Should we just retry a number of times and then fail?
>
> It's better to get stuck in an infinite loop than to cause random I/O
> errors. The infinite loop requires reboot, but it doesn't damage data on
> disks.
Fair.
>
> The proper solution would be to add the request to a queue and process the
> queue when some other request ended
This is tricky. We explored a solution that was enqueuing to a sw queue
when the hw queue was full and then re-submitting in the callback.
Didn't work due to response ordering.
> - but it would need substantial
> rewrite of the driver. Do you want to rewrite it using a queue?
We are looking at using the crypto-engine for this. However, since that
patch is not ready, we can use your solution for the time being.
I asked our validation team to run our regression suite on your patch
set.
> > Or, should we just move to the crypto-engine?
> What do you mean by the crypto-engine?
Herbert answered already this question :-)
https://www.kernel.org/doc/html/latest/crypto/crypto_engine.html
> > > - do {
> > > - ret = adf_send_message(ctx->inst->sym_tx, (uint32_t *)msg);
> > > - } while (ret == -EAGAIN && ctr++ < 10);
> > > -
> > > + qat_req->backed_off = backed_off =
> > > adf_should_back_off(ctx->inst->sym_tx);
> > checkpatch: line over 80 characters - same in every place
> > adf_should_back_off is used.
>
> Recently, Linus announced that we can have larger lines than 80 bytes.
> See bdc48fa11e46f867ea4d75fa59ee87a7f48be144
>From bdc48fa11 I see that "80 columns is certainly still _preferred_".
80 is still my preference.
I can fix this and send a v2.
>
> > > static int qat_alg_skcipher_blk_decrypt(struct skcipher_request *req)
> > > Index: linux-2.6/drivers/crypto/qat/qat_common/adf_transport.c
> > > ===================================================================
> > > --- linux-2.6.orig/drivers/crypto/qat/qat_common/adf_transport.c
> > > +++ linux-2.6/drivers/crypto/qat/qat_common/adf_transport.c
> > > @@ -114,10 +114,19 @@ static void adf_disable_ring_irq(struct
> > > WRITE_CSR_INT_COL_EN(bank->csr_addr, bank->bank_number, bank->irq_mask);
> > > }
> > >
> > > +bool adf_should_back_off(struct adf_etr_ring_data *ring)
> > > +{
> > > + return atomic_read(ring->inflights) >
> > > ADF_MAX_INFLIGHTS(ring->ring_size, ring->msg_size) * 15 / 16;
> > How did you came up with 15/16?
>
> I want the sender to back off before the queue is full, to avoid
> busy-waiting. There may be more concurrent senders, so we want to back off
> at some point before the queue is full.
Yes, I understood this. My question was about the actual number.
93% of the depth of the queue.
> > checkpatch: WARNING: line over 80 characters
> >
> > > +}
> > > +
> > > int adf_send_message(struct adf_etr_ring_data *ring, uint32_t *msg)
> > > {
> > > - if (atomic_add_return(1, ring->inflights) >
> > > - ADF_MAX_INFLIGHTS(ring->ring_size, ring->msg_size)) {
> > > + int limit = ADF_MAX_INFLIGHTS(ring->ring_size, ring->msg_size);
> > > +
> > > + if (atomic_read(ring->inflights) >= limit)
> > > + return -EAGAIN;
>
> > Can this be removed and leave only the condition below?
> > Am I missing something here?
>
> atomic_read is light, atomic_add_return is heavy. We may be busy-waiting
> here, so I want to use the light instruction. Spinlocks do the same - when
> they are spinning, they use just a light "read" instruction and when the
> "read" instruction indicates that the spinlock is free, they execute the
> read-modify-write instruction to actually acquire the lock.
Ok makes sense. Thanks.
Regards,
--
Giovanni
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
