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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0F26C76196 for ; Mon, 3 Apr 2023 19:59:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232773AbjDCT7n (ORCPT ); Mon, 3 Apr 2023 15:59:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232364AbjDCT7l (ORCPT ); Mon, 3 Apr 2023 15:59:41 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF7DAD7 for ; Mon, 3 Apr 2023 12:59:40 -0700 (PDT) Received: from [192.168.2.163] (109-252-124-32.nat.spd-mgts.ru [109.252.124.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by madras.collabora.co.uk (Postfix) with ESMTPSA id 4B534660313D; Mon, 3 Apr 2023 20:59:38 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1680551979; bh=zSQYwYndd2ZkXF8gAMJqDSt3JLQqZ/V49jQOay+yYh0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=gmZTC9WgGEnkIJRbZHhDIpRyiFsupcwjPbNtMgslR/51LDLLd5HmQn8sqR/dESI+1 EconZcSC1VbR4oKxOMBOVjzgogZLjWd3LHkWimqGYNrO6oZKBjV7Kl0CquIQZjA6n1 X08RkSBI362i7jevCEn2j1MxdLj7K99mNfXNkBD6mEOtSEqEjNayEC2BZxUUUhz5KA EKKkdwpOtXymF7WmVTRPIrAIMCydIjYhd7WzwROta2zKBoJF/WnXXODKmoQpMGuFMk 2pgOQDEhIgWdf2nuISrD9pVw6124hOBt+tUXCYBTvRudhk3vII3t7bK/Jdz1dWSxgX gMNBSgm82G1/w== Message-ID: <699f2130-11be-e0db-5f7f-ff53dc3a46fc@collabora.com> Date: Mon, 3 Apr 2023 22:59:35 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v4 1/2] drm/virtio: Refactor job submission code path Content-Language: en-US To: Emil Velikov Cc: David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , Daniel Vetter , Rob Clark , =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= , Pierre-Eric Pelloux-Prayer , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kernel@collabora.com, virtualization@lists.linux-foundation.org References: <20230323230755.1094832-1-dmitry.osipenko@collabora.com> <20230323230755.1094832-2-dmitry.osipenko@collabora.com> From: Dmitry Osipenko In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/30/23 18:32, Emil Velikov wrote: >> +static int virtio_gpu_dma_fence_wait(struct virtio_gpu_submit *submit, >> + struct dma_fence *fence) >> +{ >> + struct dma_fence_unwrap itr; >> + struct dma_fence *f; >> + int err; >> + >> + dma_fence_unwrap_for_each(f, &itr, fence) { > The dma_fence_unwrap_for_each() change should be a separate patch, > highlighting why we want it. Good point, it actually should be a potential optimization for the in-fence waiting. >> + ret = virtio_gpu_init_submit(&submit, exbuf, dev, file, >> + fence_ctx, ring_idx); >> + if (ret) >> + goto cleanup; >> + >> + ret = virtio_gpu_wait_in_fence(&submit); >> + if (ret) >> + goto cleanup; >> + > We have reshuffled the order around in_fence waiting, out_fence install, > handles, cmdbuf, drm events, etc. Can we get that split up a bit, with > some comments. > > If it were me, I would keep the wait_in_fence early and inline > virtio_gpu_init_submit (the nesting/abstraction seems a bit much). This > means one can omit the virtio_gpu_submit::exbuf all together. I tried to inline and this variant makes code much less readable to me. The point of having wait_in_fence after submit_init is that it makes submit code path shorter. If we have to wait for in-fence, then once fence signals, there is no need to init and instead move directly to a further submission step. Perhaps won't hurt to also factor out the wait_fence from parse_deps in the second patch and do all the waits right before locking the buflist. -- Best regards, Dmitry