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: <CACGkMEtydc4q5Dc1wwN52na37uWLf24e-Tmp6rYmKyg0TDgXUg@mail.gmail.com>
Date: Fri, 6 Dec 2024 10:38:15 +0800
From: Jason Wang <jasowang@...hat.com>
To: Shijith Thotton <sthotton@...vell.com>
Cc: virtualization@...ts.linux.dev, mst@...hat.com, dan.carpenter@...aro.org, 
	schalla@...vell.com, vattunuru@...vell.com, ndabilpuram@...vell.com, 
	jerinj@...vell.com, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, 
	Eugenio Pérez <eperezma@...hat.com>, 
	Satha Rao <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

On Thu, Nov 21, 2024 at 9:43 PM Shijith Thotton <sthotton@...vell.com> wrote:
>
> 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.

>
> 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?

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.

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