Re: [PATCH v2 4/4] vdpa/octeon_ep: add interrupt handler for virtio crypto device

[Shijith Thotton]

>> Introduced an interrupt handler for the virtio crypto device, as its
>> queue usage differs from that of network devices. While virtio network
>> device receives packets only on even-indexed queues, virtio crypto
>> device utilize all available queues for processing data.
>
>I'm not sure I will get here but the recent kernel depends heavily on
>the tx interrupt for skb post processing as well.
>

Currently, the device does not support TX interrupts.
This behavior may change in the future.  

>>
>> Signed-off-by: Shijith Thotton <sthotton@xxxxxxxxxxx>
>> ---
>>  drivers/vdpa/octeon_ep/octep_vdpa_main.c | 52
>+++++++++++++++++++++++-
>>  1 file changed, 50 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/vdpa/octeon_ep/octep_vdpa_main.c
>b/drivers/vdpa/octeon_ep/octep_vdpa_main.c
>> index d674b9678428..1bdf7a8111ce 100644
>> --- a/drivers/vdpa/octeon_ep/octep_vdpa_main.c
>> +++ b/drivers/vdpa/octeon_ep/octep_vdpa_main.c
>> @@ -44,7 +44,35 @@ static struct octep_hw *vdpa_to_octep_hw(struct
>vdpa_device *vdpa_dev)
>>         return oct_vdpa->oct_hw;
>>  }
>>
>> -static irqreturn_t octep_vdpa_intr_handler(int irq, void *data)
>> +static irqreturn_t octep_vdpa_crypto_irq_handler(int irq, void *data)
>> +{
>> +       struct octep_hw *oct_hw = data;
>> +       int i;
>> +
>> +       /* Each device interrupt (nb_irqs) maps to specific receive rings
>> +        * (nr_vring) in a round-robin fashion.
>> +        *
>> +        * For example, if nb_irqs = 8 and nr_vring = 64:
>> +        * 0 -> 0, 8, 16, 24, 32, 40, 48, 56;
>> +        * 1 -> 1, 9, 17, 25, 33, 41, 49, 57;
>> +        * ...
>> +        * 7 -> 7, 15, 23, 31, 39, 47, 55, 63;
>> +        */
>
>So this algorithm is mandated by the device?
>

Yes.

>I'm asking since it's better to not have type specific policy in the
>vDPA layer. As the behaviour of the guest might change.
>

This logic is closely linked to the device's behavior. I will check if it is
possible to avoid the device-type-based logic.  

>For example, for networking devices, in the future we may switch to
>use a single interrupt/NAPI to handle both RX and TX. And note that
>this is only the behaviour of Linux, not other drivers like DPDK or
>other OSes.
>
>> +       for (i = irq - oct_hw->irqs[0]; i < oct_hw->nr_vring; i += oct_hw->nb_irqs)
>{
>> +               if (ioread32(oct_hw->vqs[i].cb_notify_addr)) {
>> +                       /* Acknowledge the per ring notification to the device */
>> +                       iowrite32(0, oct_hw->vqs[i].cb_notify_addr);
>> +
>> +                       if (likely(oct_hw->vqs[i].cb.callback))
>> +                               oct_hw->vqs[i].cb.callback(oct_hw->vqs[i].cb.private);
>> +                       break;
>> +               }
>> +       }
>

Thanks,
Shijith