From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2CBBC11F68 for ; Fri, 2 Jul 2021 10:43:29 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 403F36141C for ; Fri, 2 Jul 2021 10:43:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 403F36141C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AD6376E0EA; Fri, 2 Jul 2021 10:43:28 +0000 (UTC) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by gabe.freedesktop.org (Postfix) with ESMTPS id 242356E0EA for ; Fri, 2 Jul 2021 10:43:27 +0000 (UTC) Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id DB3DC1F43802; Fri, 2 Jul 2021 11:43:24 +0100 (BST) Date: Fri, 2 Jul 2021 12:43:20 +0200 From: Boris Brezillon To: Steven Price Subject: Re: [PATCH v2 4/7] drm/panfrost: Add the ability to create submit queues Message-ID: <20210702124320.1bd0f228@collabora.com> In-Reply-To: References: <20210701091224.3209803-1-boris.brezillon@collabora.com> <20210701091224.3209803-5-boris.brezillon@collabora.com> Organization: Collabora X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jason Ekstrand , Tomeu Vizoso , dri-devel@lists.freedesktop.org, Rob Herring , Alyssa Rosenzweig , Robin Murphy Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, 2 Jul 2021 10:56:29 +0100 Steven Price wrote: > On 01/07/2021 10:12, Boris Brezillon wrote: > > Needed to keep VkQueues isolated from each other. > > > > Signed-off-by: Boris Brezillon > > My Vulkan knowledge is limited so I'm not sure whether this is the right > approach or not. In particular is it correct that an application can > create a high priority queue which could affect other (normal priority) > applications? That's what msm does (with no extra CAPS check AFAICT), and the freedreno driver can already create high priority queues if PIPE_CONTEXT_HIGH_PRIORITY is passed. Not saying that's okay to allow userspace to tweak the priority, but if that's a problem, other drivers are in trouble too ;-). > > Also does it really make sense to allow user space to create an > unlimited number of queues? It feels like an ideal way for an malicious > application to waste kernel memory. Same here, I see no limit on the number of queues the msm driver can create. I can definitely pick an arbitrary limit of 2^16 (or 2^8 if 2^16 is too high) if you prefer, but I feel like there's plenty of ways to force kernel allocations already, like allocating a gazillion of 4k GEM buffers (cgroup can probably limit the total amount of memory allocated, but you'd still have all gem-buf meta data in kernel memory). > > In terms of implementation it looks correct, but one comment below > > > --- > > drivers/gpu/drm/panfrost/Makefile | 3 +- > > drivers/gpu/drm/panfrost/panfrost_device.h | 2 +- > > drivers/gpu/drm/panfrost/panfrost_drv.c | 69 ++++++++-- > > drivers/gpu/drm/panfrost/panfrost_job.c | 47 ++----- > > drivers/gpu/drm/panfrost/panfrost_job.h | 9 +- > > .../gpu/drm/panfrost/panfrost_submitqueue.c | 130 ++++++++++++++++++ > > .../gpu/drm/panfrost/panfrost_submitqueue.h | 27 ++++ > > include/uapi/drm/panfrost_drm.h | 17 +++ > > 8 files changed, 258 insertions(+), 46 deletions(-) > > create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.c > > create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.h > > > [...] > > diff --git a/drivers/gpu/drm/panfrost/panfrost_submitqueue.c b/drivers/gpu/drm/panfrost/panfrost_submitqueue.c > > new file mode 100644 > > index 000000000000..98050f7690df > > --- /dev/null > > +++ b/drivers/gpu/drm/panfrost/panfrost_submitqueue.c > > @@ -0,0 +1,130 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* Copyright 2021 Collabora ltd. */ > > + > > +#include > > + > > +#include "panfrost_device.h" > > +#include "panfrost_job.h" > > +#include "panfrost_submitqueue.h" > > + > > +static enum drm_sched_priority > > +to_sched_prio(enum panfrost_submitqueue_priority priority) > > +{ > > + switch (priority) { > > + case PANFROST_SUBMITQUEUE_PRIORITY_LOW: > > + return DRM_SCHED_PRIORITY_MIN; > > + case PANFROST_SUBMITQUEUE_PRIORITY_MEDIUM: > > + return DRM_SCHED_PRIORITY_NORMAL; > > + case PANFROST_SUBMITQUEUE_PRIORITY_HIGH: > > + return DRM_SCHED_PRIORITY_HIGH; > > + default: > > + break; > > + } > > + > > + return DRM_SCHED_PRIORITY_UNSET; > > +} > > + > > +static void > > +panfrost_submitqueue_cleanup(struct kref *ref) > > +{ > > + struct panfrost_submitqueue *queue; > > + unsigned int i; > > + > > + queue = container_of(ref, struct panfrost_submitqueue, refcount); > > + > > + for (i = 0; i < NUM_JOB_SLOTS; i++) > > + drm_sched_entity_destroy(&queue->sched_entity[i]); > > + > > + /* Kill in-flight jobs */ > > + panfrost_job_kill_queue(queue); > > + > > + kfree(queue); > > +} > > + > > +void panfrost_submitqueue_put(struct panfrost_submitqueue *queue) > > +{ > > + if (!IS_ERR_OR_NULL(queue)) > > + kref_put(&queue->refcount, panfrost_submitqueue_cleanup); > > +} > > + > > +struct panfrost_submitqueue * > > +panfrost_submitqueue_create(struct panfrost_file_priv *ctx, > > + enum panfrost_submitqueue_priority priority, > > + u32 flags) > > If this function returned an 'int' we could simplify some code. So > instead of returning the struct panfrost_submitqueue just return the ID > (or negative error). The only caller (panfrost_ioctl_create_submitqueue) > doesn't actually want the object just the ID and we can ditch the 'id' > field from panfrost_submitqueue. Sure, I can do that.