From: Christoph Hellwig <hch@lst.de>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Christoph Hellwig <hch@lst.de>, Tomasz Figa <tfiga@chromium.org>,
Robin Murphy <robin.murphy@arm.com>, Anle Pan <anle.pan@nxp.com>,
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
Date: Fri, 1 Sep 2023 08:10:14 +0200 [thread overview]
Message-ID: <20230901061014.GA32166@lst.de> (raw)
In-Reply-To: <ZPCylmcRD0hwluZf@ziepe.ca>
On Thu, Aug 31, 2023 at 12:32:38PM -0300, Jason Gunthorpe wrote:
> 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.
How do you get away with a 8 byte entry for addr+len?
> 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.
That's what I'd expect.
> 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.
So for the first version I see no need to change the bio_vec
representation as part of this project, but at the same time the
bio_vec representation causes problems for other reasons. So I want
to change it anyway.
next prev parent reply other threads:[~2023-09-01 6:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-28 7:54 [PATCH] media: videobuf2-dma-sg: limit the sg segment size Anle Pan
2023-08-29 10:03 ` Tomasz Figa
2023-08-29 11:14 ` Robin Murphy
2023-08-29 15:04 ` Christoph Hellwig
2023-08-30 3:47 ` Tomasz Figa
2023-08-30 14:33 ` Christoph Hellwig
2023-08-30 16:43 ` Jason Gunthorpe
2023-08-31 12:35 ` Christoph Hellwig
2023-08-31 15:32 ` Jason Gunthorpe
2023-09-01 6:10 ` Christoph Hellwig [this message]
2023-09-01 14:26 ` Jason Gunthorpe
[not found] ` <DB9PR04MB92841D8BC1122D5A4210F78987E6A@DB9PR04MB9284.eurprd04.prod.outlook.com>
2023-08-30 13:41 ` [EXT] " Robin Murphy
2023-08-30 3:59 ` Tomasz Figa
2023-09-06 8:52 ` Hans Verkuil
2023-09-06 9:26 ` Tomasz Figa
2023-09-06 9:43 ` Hans Verkuil
2023-08-30 8:50 ` Hui Fang
2023-08-30 9:28 ` Tomasz Figa
2023-09-04 7:10 ` [EXT] " Hui Fang
2023-09-05 3:43 ` Tomasz Figa
2023-09-06 8:16 ` Hui Fang
2023-09-06 9:28 ` Tomasz Figa
2023-09-11 6:13 ` Hui Fang
2023-09-12 2:22 ` Tomasz Figa
2023-09-12 7:01 ` Hui Fang
2023-09-12 7:10 ` Tomasz Figa
2023-09-12 7:43 ` Hui Fang
2023-09-12 7:51 ` Tomasz Figa
2023-09-13 9:13 ` Hui Fang
2023-09-13 9:44 ` Tomasz Figa
2023-09-13 13:16 ` Hui Fang
2023-09-18 2:28 ` Hui Fang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230901061014.GA32166@lst.de \
--to=hch@lst.de \
--cc=anle.pan@nxp.com \
--cc=hui.fang@nxp.com \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=robin.murphy@arm.com \
--cc=tfiga@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.