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 98AB6C83F10 for ; Thu, 31 Aug 2023 15:32:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346617AbjHaPcr (ORCPT ); Thu, 31 Aug 2023 11:32:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51196 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344831AbjHaPcq (ORCPT ); Thu, 31 Aug 2023 11:32:46 -0400 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 91251E54 for ; Thu, 31 Aug 2023 08:32:41 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-68bed2c786eso783474b3a.0 for ; Thu, 31 Aug 2023 08:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1693495961; x=1694100761; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=6oic3RLhjJLFMRrnh/TLgKdT1bBdDLhHF0St+2zs/cM=; b=PQbw4+MA5oR9V7gfDDgDxXWUekmTc9PXT9hPcfvLEsT0E2WWtota7JLrpDkyYF12qC QGyIsZzcaZUCcIYnYQQfl1p3n7eyxkgARJR5VgCV1T8UObLXUKGB1LIQ++hAxa/TMIOn y6y0WQrl28afU5z3AJPjSG3RhsZIrWWQP8TWsd8Bu3NPSRGLJkC2AKsDkX8qf3gegtfK bu836x1VFxgBvQpsr7sp4Z5MvGrW3DUgVetEBxSHmNWrsylT7y31wXPVIaTUFugQ2kJY mqJ/ALmTY4ifCogB+NsdTnaxKxico+7U1EbXvbL8A9TFTwUxyz+g+YtWjneuXyIMrcrQ 65Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693495961; x=1694100761; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6oic3RLhjJLFMRrnh/TLgKdT1bBdDLhHF0St+2zs/cM=; b=hGolYGFdW6oHaSs6rr4y6h5YP8aitsuaxFw5qt2NbzE+bVW+Cqz57OT4xrIQEPNL4y cjYtaD0KqiRHRIlCBq2I8MXQNc68TPF7Y0pZVL9Lx6AnwQfuRI1fKLpUFoM4QXluDr/l D4FoBI3Qlj3hk0MlwXy9oFhPQ93eYZkm7syWVQSXgO0JL6HEGQb4opvLN3KhX3+CKDoR eg43ZHLRYR/yCMOr4cSxP6rETOyZ0Xm952K2zHhXGdRtDA9Oz8jGtCWryk9jWVsV8CJ2 9LQA+yRY+GHAWWhjyI7Xz1Du2K3lxQkOLJ/3P9Uzdh6gbW62i0Z45eYTAfidLtvnFnle uJ4g== X-Gm-Message-State: AOJu0Yy+CekzdEbJdh5jBr5Z9z23eLUL3LxGk5oMgJyI4YTViwp2mTNM 7Q2EdSIgdg6Uhd3XezX1FKHgdg== X-Google-Smtp-Source: AGHT+IF5KLLO7/so1cpnK0Z4cYL6heHXJbzhg5chsQzO6cjO+0canVLzcMfdojFa0XNIv4ieQ/49cA== X-Received: by 2002:a05:6a00:17a3:b0:68c:3f2:6006 with SMTP id s35-20020a056a0017a300b0068c03f26006mr2563pfg.16.1693495960988; Thu, 31 Aug 2023 08:32:40 -0700 (PDT) Received: from ziepe.ca ([207.140.200.197]) by smtp.gmail.com with ESMTPSA id bm2-20020a056a00320200b00682a61fa525sm1499015pfb.91.2023.08.31.08.32.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Aug 2023 08:32:40 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1qbjew-000Hon-9J; Thu, 31 Aug 2023 12:32:38 -0300 Date: Thu, 31 Aug 2023 12:32:38 -0300 From: Jason Gunthorpe To: Christoph Hellwig Cc: Tomasz Figa , Robin Murphy , Anle Pan , m.szyprowski@samsung.com, mchehab@kernel.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, hui.fang@nxp.com Subject: Re: [PATCH] media: videobuf2-dma-sg: limit the sg segment size Message-ID: References: <20230828075420.2009568-1-anle.pan@nxp.com> <20230829150442.GA3929@lst.de> <20230830143341.GA25574@lst.de> <20230831123532.GA11156@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230831123532.GA11156@lst.de> Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Thu, Aug 31, 2023 at 02:35:32PM +0200, Christoph Hellwig wrote: > On Wed, Aug 30, 2023 at 01:43:57PM -0300, Jason Gunthorpe wrote: > > > > conversion function for the drivers. > > > > > > Jason said at LSF/MM that he had a prototype for a mapping API that > > > takes a phys/len array as input and dma_addr/len a output, which really > > > is the right thing to do, especially for dmabuf. > > > > Yes, still a prototype. Given the change in direction some of the > > assumptions of the list design will need some adjusting. > > > > I felt there wasn't much justification to add a list without also > > supporting the P2P and it was not looking very good to give the DMA > > API proper p2p support without also connecting it to lists somehow. > > > > Anyhow, I had drafted a basic list datastructure and starting > > implementation that is sort of structured in away that is similar to > > xarray (eg with fixed chunks, generic purpose, etc) > > > > https://github.com/jgunthorpe/linux/commit/58d7e0578a09d9cd2360be515208bcd74ade5958 > > This seems fairly complicated complicated, and the entry seems pretty large > for a bio_vec replacement or a dma_addr_t+len tuple, which both should > be (sizeof(phys_addr_t) + sizeof(u32) + the size of flags if needed, which > for 64-bit would fit into the padding from 96 bytes to 128 bytes anyway. The entry is variable sized, so it depends on what is stuffed in it. For alot of common use cases, especially RDMA page lists, it will be able to use an 8 byte entry. This is pretty much the most space efficient it could be. There are RDMA use cases where we end up holding huge numbers of pages for a long time just so we can eventually unpin them. It is a nice outcome if that could use 8 bytes/folio. The primary alternative I see is a fixed 16 bytes/entry with a 64 bit address and ~60 bit length + ~4 bits of flags. This is closer to bio, simpler and faster, but makes the RDMA cases 2x bigger. Which are the right trade offs, or not, I don't know yet. I wanted to experiment with what this would look like for a bit. With your direction I felt we could safely keep bio as it is and cheaply make a fast DMA mapper for it. Provide something like this as the 'kitchen sink' version for dmabuf/rdma/etc that are a little different. Jason