>>> 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.
>
I will drop this patch and update the interrupt handler in the first patch of
the series to manage both devices.
>>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;
>>> + }
>>> + }
>>
