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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PH0PR18MB442581F8A6914C40E0FEE414D9312@PH0PR18MB4425.namprd18.prod.outlook.com>
Date: Fri, 6 Dec 2024 11:58:42 +0000
From: Shijith Thotton <sthotton@...vell.com>
To: Jason Wang <jasowang@...hat.com>
CC: "virtualization@...ts.linux.dev" <virtualization@...ts.linux.dev>,
        "mst@...hat.com" <mst@...hat.com>,
        "dan.carpenter@...aro.org"
	<dan.carpenter@...aro.org>,
        Srujana Challa <schalla@...vell.com>,
        Vamsi
 Krishna Attunuru <vattunuru@...vell.com>,
        Nithin Kumar Dabilpuram
	<ndabilpuram@...vell.com>,
        Jerin Jacob <jerinj@...vell.com>,
        Xuan Zhuo
	<xuanzhuo@...ux.alibaba.com>,
        Eugenio Pérez
	<eperezma@...hat.com>,
        Satha Koteswara Rao Kottidi <skoteshwar@...vell.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 4/4] vdpa/octeon_ep: add interrupt handler for virtio
 crypto device

>> 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@...vell.com>
>> ---
>>  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