Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4510022pxj; Tue, 22 Jun 2021 01:44:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyFHZyClzwNFOULegoG183rYeMmZ5b+4EhGlJX0+cFreL+UhhnnQGbGZI1ikLiaGLj2DK8i X-Received: by 2002:a17:907:1b1b:: with SMTP id mp27mr2742328ejc.538.1624351499437; Tue, 22 Jun 2021 01:44:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624351499; cv=none; d=google.com; s=arc-20160816; b=Vcfve+4ESOUdhalVd8hGbYYtQqGW89nCgQj/9Mpsu6KGOHlooSCmnUwwXIsqBPOpTS ATDSz4hMq7O1vi0nVkvnz4y0UQLrXBUfY0czeRf/tl4q+F6YTcHUksiId5X735zf8gRw d+bLlfGUtTipzm2fD7q+OlgGXWf5X1X9+/rFUScg9bi7uJtMEZyZnofTGuYB9mMwghQ9 WeYnJbhSsu7lPv6ek1hKvN162Qx0F1cQOh2ZLTVrBBu1xLFUdayjqSPpETPVLtKndHBz g2YzY0SzI2HShn+B34HKYb8hb2jIqXFeXFEGJINuH1mz8PYSM5HuyxMze7SMUWB8IDa4 3PuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Wk5uHooOe9m9o4Li9n5UAmr51NiBBmwNJ7AeW2XMF1s=; b=rV0uUVXb+oUvEV8kmQZZrYTOngbIVdZN759vdVUowpNHnB4teIj/As5SFbPGcjvqZf yHODvod7I4mQeVeaVU0rielj9eIDbBZznNBov7rUMmAjehZ89SlkSsaZPnxxNyVbcELv YYO07239TX4fL75JO2ZzOujdEM9p0dtslPDzQ+rcinkx6eBrfDB+JBKLtzDx/xjS+HtT liuNaSO16hILgk7Al6D4kewtxNvRW9JHS8VcHBNy9p42vYGTVpENeKltrKBWoTLFoK/m lfDDKdVL1yMhJvmfSSSY/MHyeuJwKxirGpKNjH1utpBOzv47gkVCmQnBoV2/lIjhAZLX CMyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="DpDeRnU/"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h8si20951128edj.149.2021.06.22.01.44.37; Tue, 22 Jun 2021 01:44:59 -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=@gmail.com header.s=20161025 header.b="DpDeRnU/"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231143AbhFVIpN (ORCPT + 99 others); Tue, 22 Jun 2021 04:45:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231127AbhFVIpK (ORCPT ); Tue, 22 Jun 2021 04:45:10 -0400 Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4365C061766; Tue, 22 Jun 2021 01:42:54 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id v5-20020a0568301bc5b029045c06b14f83so3948139ota.13; Tue, 22 Jun 2021 01:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Wk5uHooOe9m9o4Li9n5UAmr51NiBBmwNJ7AeW2XMF1s=; b=DpDeRnU/4unkLfeKoqfIKEFsfBMZFLBF8xKaZiqlTL9oc6P670t4XFLRq0TbDdE6nr Ztf3mV6Jahqo5RivMEWXCClTKbKDMDe6c7CL3y9QiJTZt8/r2DB9HhkBvxBCH8TrEfdm Rt/c8fK3pi38t+F5QDTk0+rxauu4yuqIqdSUlpvdAhK+1McLQSnLZ32JDHCpHLb58xJG 9PLhewIvLG/dnvIOahxYSNKAxU8IZKlfkXFiSxdV5+C0PGXWM7yX0apmRtf4EIruhPsC ZdnMtoc3+SsuyvZ4RQOwY5D2Bxf48aWo0hzb8v20huhOrOF7qWZgFU7vlfk5rpemBNeB mw9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Wk5uHooOe9m9o4Li9n5UAmr51NiBBmwNJ7AeW2XMF1s=; b=q4AKlySAvLP8hjry30pD4NVYpa5kqUhRKwuDzSDweh7Z6yw2frvxAZGYWVk+FUy6h+ ebBEc+WwxHcI08xhUPGfKeUKi8sjmpZYCXQpxxPrf6itgUaD5vK6lYRwiWyIyANzIwok SDgXQ5cLopf+Txmdxfr6j2tpfM/lxkZ+jMCkujVw3UcHyRqS2Jl0AAG0Xzb9hUJfg0aK vEXWwVEXBPhyrrsMYfA5vo4vptWnXQEvMUBDPn6Dgj8MLnlQllKEULMAtO6om5LMSxqe /GF9WM6AObDWDfX4tM4Ogc/CftT9p/ef2PQcwUIldPEGG0r7dywRUMwUYsKecwF4oOWp lWqQ== X-Gm-Message-State: AOAM530hVJagvdtC6BzNhDcTVLNzouPVjQwfDcALDenYp79+pc0TTv6t tj/l97qBKlbHTSRDekuJtmrqQUv9p2h2DOXK7LM= X-Received: by 2002:a9d:509:: with SMTP id 9mr2169190otw.339.1624351373978; Tue, 22 Jun 2021 01:42:53 -0700 (PDT) MIME-Version: 1.0 References: <20210618123615.11456-1-ogabbay@kernel.org> <20210621141217.GE1096940@ziepe.ca> <20210621175511.GI1096940@ziepe.ca> <20210621232912.GK1096940@ziepe.ca> In-Reply-To: From: Oded Gabbay Date: Tue, 22 Jun 2021 11:42:27 +0300 Message-ID: Subject: Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: Jason Gunthorpe , Gal Pressman , sleybo@amazon.com, linux-rdma , Oded Gabbay , Christoph Hellwig , Linux Kernel Mailing List , dri-devel , =?UTF-8?Q?Christian_K=C3=B6nig?= , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Doug Ledford , Tomer Tayar , amd-gfx list , Greg KH , Alex Deucher , Leon Romanovsky , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 22, 2021 at 9:37 AM Christian K=C3=B6nig wrote: > > Am 22.06.21 um 01:29 schrieb Jason Gunthorpe: > > On Mon, Jun 21, 2021 at 10:24:16PM +0300, Oded Gabbay wrote: > > > >> Another thing I want to emphasize is that we are doing p2p only > >> through the export/import of the FD. We do *not* allow the user to > >> mmap the dma-buf as we do not support direct IO. So there is no access > >> to these pages through the userspace. > > Arguably mmaping the memory is a better choice, and is the direction > > that Logan's series goes in. Here the use of DMABUF was specifically > > designed to allow hitless revokation of the memory, which this isn't > > even using. > > The major problem with this approach is that DMA-buf is also used for > memory which isn't CPU accessible. > > That was one of the reasons we didn't even considered using the mapping > memory approach for GPUs. > > Regards, > Christian. > > > > > So you are taking the hit of very limited hardware support and reduced > > performance just to squeeze into DMABUF.. Thanks Jason for the clarification, but I honestly prefer to use DMA-BUF at the moment. It gives us just what we need (even more than what we need as you pointed out), it is *already* integrated and tested in the RDMA subsystem, and I'm feeling comfortable using it as I'm somewhat familiar with it from my AMD days. I'll go and read Logan's patch-set to see if that will work for us in the future. Please remember, as Daniel said, we don't have struct page backing our device memory, so if that is a requirement to connect to Logan's work, then I don't think we will want to do it at this point. Thanks, Oded > > > > Jason > > _______________________________________________ > > Linaro-mm-sig mailing list > > Linaro-mm-sig@lists.linaro.org > > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig >