Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1209327ybh; Mon, 13 Jul 2020 12:08:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxoIiFSu8ZWhtFUde0zrqrrK/NXptB9c5GNfnTPm5Ndrm/YhgR616CVczsr8u7Q2NhRmZvI X-Received: by 2002:a17:906:5006:: with SMTP id s6mr1135149ejj.294.1594667280691; Mon, 13 Jul 2020 12:08:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594667280; cv=none; d=google.com; s=arc-20160816; b=UTejr+1ub0oPptRu+5lT8lgnQfR4jxUUQVM9uzcI3qEbIsNE4FODcK2xjNURqsgzr/ 0BSGpQ8NLzBeBRjcLAYp1962btHG9cH5RfNhapC/jVNGgd6zyRWDxGGMbQJatEO/5oLe e2DGuC3YFj5GE5q51hmtTblJ+BwERNh5eQ5hqbHF1xfvGinUzO6NWtAnlG1J5agtGiMn d37X3V1GCW5vwcH1Qb12mkvD3n1LIKCKtmLXnWul0gb0naVmcjDrzyS0y8eVr9VFsQxR 547OWlQnPpr5ivjCjzRf077YUjqMJEi4IphZV1hDztJl90n/G1Ao4QsUlZ5e1uNKi1ox oXNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=XA1EpHrdmYjsC6ofF2H7iz3RZthRfSSjC9rfBgRGN6M=; b=ldQCe/I35A+dhhSh/1G42EVs6fQy7eZu7bkBQ9k4QyAG45WG2qnikKEUkcdfr/Mmj2 n2kRhjhgyxsLi8uRcgLkWNpeL0P+8ezbczGc+2EbE8jp9LyLgrEPDzbgnTsFVGnshhe3 cJ6A3R6qO6P8hQEjoo63TnF/utfeRx6j/c1I6rWQ3Jfa50k4/KxckB4p6pDRzbRpA+d3 j8PsSjDXGc3Tk/+Mn9hIX0rlrAXnBsLnk1Zv3SDkLMnqEHbF+v2IAv+sxQW8QZ8L8fuV Qy33GgTvmbgKPjzAUTYqEBZIOmM/NCC6NwhDN+eoWwDKEf/2z0agIfgn/Y7+neaCFBgS r78A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b="VWDGXW/N"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c68si10045507edf.428.2020.07.13.12.07.37; Mon, 13 Jul 2020 12:08:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b="VWDGXW/N"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726974AbgGMTEA (ORCPT + 99 others); Mon, 13 Jul 2020 15:04:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726338AbgGMTEA (ORCPT ); Mon, 13 Jul 2020 15:04:00 -0400 Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01B7BC061755 for ; Mon, 13 Jul 2020 12:04:00 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id i18so12149274ilk.10 for ; Mon, 13 Jul 2020 12:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=XA1EpHrdmYjsC6ofF2H7iz3RZthRfSSjC9rfBgRGN6M=; b=VWDGXW/NXw25gdZJAvtRUIvPTZDkBqrgY3CT2vzlzhRjMcRQIxRLBAnCJ3lpKSJpFE xT0tyMQ0kws9PblSt76PpMPaVVDnfI0c8WDxS8ltFpz/oNNfxz9BkUOdx2EQgjyR+YY/ YlkbxjOna4FFyv5rCJXy94vXpvS1KnQJY4K0lKyVZm9AlDkywFjXCRoGsnMlp1XaLDK4 +2wyPVNbDhyGrwQlxKnFaRcbj6BKXFsVhmyjq1XvZOE4nnuFLOfi0oyhx/ODt8ces/LL ati5yeNujl4IhJvCI6cN+Dbau+wRoRKvlWhK3sOJ2J4f5tkaCxtF/q/LXuZjOapBQPD3 zrfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XA1EpHrdmYjsC6ofF2H7iz3RZthRfSSjC9rfBgRGN6M=; b=eS2aimE7U/LYLkSiQN6kG4co2sQ6f/iMAjPF7PmYMTRjDFC9WAMYixa2D+Nn62jO1Z rg7rk0zWv2BTOaiMn5lWssQoTzfEhdBSIgZlTaI+x0C8yr9XuXM9oNVkLO2BkQtMu9rw 5OIFB3qQzYR3XehFdMV/fW6KqVHT0IJyCKhvhXRGoKEHIeBC2wxy3Rgt/8WFMwlC8VXk uwnzn1mkAVK5A7H/n+iY96dTmZiw+53aKrw0VLHj7Jkx8SpZp9V2zxzM7UQooXhfZVC4 u3DxeF9fYoFdoHzDTA63kSRYDJWJOTYrqTOlJm4vC2OzO85DY1MnOHE8x9/jHrlOaHRg 5N0A== X-Gm-Message-State: AOAM530Vgb/xdWgseSpGmJkgqF9PprvmAL/XK2aQ1v3GTFyBad820Xpz yXjG0W6wmKxthN6FF5UcAG0Xtg== X-Received: by 2002:a92:c7c3:: with SMTP id g3mr1271721ilk.164.1594667039054; Mon, 13 Jul 2020 12:03:59 -0700 (PDT) Received: from ziepe.ca ([206.223.160.26]) by smtp.gmail.com with ESMTPSA id y6sm8676368ila.74.2020.07.13.12.03.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jul 2020 12:03:58 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.93) (envelope-from ) id 1jv3k5-009wVE-3L; Mon, 13 Jul 2020 16:03:57 -0300 Date: Mon, 13 Jul 2020 16:03:57 -0300 From: Jason Gunthorpe To: Daniel Vetter Cc: Greg Kroah-Hartman , Oded Gabbay , Linux Kernel Mailing List , SW_Drivers@habana.ai, Ofir Bitton Subject: Re: [PATCH 1/3] habanalabs: implement dma-fence mechanism Message-ID: <20200713190357.GC25301@ziepe.ca> References: <20200713155424.24721-1-oded.gabbay@gmail.com> <20200713155752.GC267581@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 13, 2020 at 08:34:12PM +0200, Daniel Vetter wrote: > On Mon, Jul 13, 2020 at 5:57 PM Greg Kroah-Hartman > wrote: > > > > On Mon, Jul 13, 2020 at 06:54:22PM +0300, Oded Gabbay wrote: > > > From: Ofir Bitton > > > > > > Instead of using standard dma-fence mechanism designed for GPU's, we > > > introduce our own implementation based on the former one. This > > > implementation is much more sparse than the original, contains only > > > mandatory functionality required by the driver. > > > > Sad you can't use the in-kernel code for this, I really don't understand > > what's wrong with using it as-is. > > > > Daniel, why do we need/want duplicate code floating around in the tree > > like this? > > The rules around dma-fence are ridiculously strict, and it only makes > sense to inflict that upon you if you actually want to participate in > the cross driver uapi built up around dma-buf and dma-fence. > > I've recently started some lockdep annotations to better enforce these > rules (and document them), and it's finding tons of subtle bugs even > in drivers/gpu (and I only just started with annotating drivers: > > https://lore.kernel.org/dri-devel/20200707201229.472834-1-daniel.vetter@ffwll.ch/ > > You really don't want to deal with this if you don't have to. If > drivers/gpu folks (who created this) aren't good enough to understand > it, maybe it's not a good idea to sprinkle this all over the tree. And > fundamentally all this is is a slightly fancier struct completion. Use > that one instead, or a wait_queue. > > I discussed this a bit with Oded, and he thinks it's easier to > copypaste and simplify, but given that all other drivers seem to get > by perfectly well with completion or wait_queue, I'm not sure that's a > solid case. > > Also adding Jason Gunthorpe, who very much suggested this should be > limited to dma-buf/gpu related usage only. Without all the cross-driver stuff dma_fence is just a completion. Using dma_fence to get a completion is big abuse of what it is intended for. I think the only problem with this patch is that it keeps too much of the dma_fence stuff around. From what I could tell it really just wants to add a kref and completion to struct hl_cs_compl and delete everything to do with dma_fence. Not even sure the kref is needed ;) Jason