Revert changing the DMA allocator via public API and use environment variables #1344
Conversation
This reverts commit 9e6895c.
This reverts commit 95dc678.
This reverts commit 58e333d.
This reverts commit 733a681.
This reverts commit 5f52c98.
This reverts commit aa867f0.
…ble at runtime" This reverts commit 8291539.
This reverts commit a7d0450.
Signed-off-by: Dan Nechita <dan.nechita@analog.com>
dNechita
changed the title
This feature is targeted for advanced users who experiment with or require alternative DMA allocators. It is to be determined if the feature becomes popular enough to be exposed through the public API or not. Signed-off-by: Dan Nechita <dan.nechita@analog.com>
dNechita
force-pushed
the
reverse-cma-go-for-env-var-approach
branch
from
62acb6c to
5dc525a
Compare
|
As I said in the original PR:
Originally posted by @rgetz in #1264 (comment) I think this is still the same. |
| - If the environment variable is not set, the default `/dev/dma_heap/system` is used | ||
|
|
||
| This feature is intended for advanced users who understand the implications of customizing DMA heap selection. It is especially useful on systems with multiple DMA heap types, allowing experienced users to exercise fine-grained control over memory allocation for specific IIO devices. | ||
|
|
There was a problem hiding this comment.
I would separate docs from the code in terms of commits...
| * Environment variable format: | ||
| * - LIBIIO_DMA_HEAP_PATH=heap_name (applies to all devices) | ||
| * - LIBIIO_DMA_HEAP_PATH=heap_name:device1 (applies only to device1) | ||
| * - LIBIIO_DMA_HEAP_PATH=heap_name:device1,device2 (applies to device1 and device2) |
There was a problem hiding this comment.
Hmm, I would make this way more simple for now. I guess the ENV var is ok (even though I would likely go for the compile time option) but make it simple. Meaning, just give in the allocator name. For now this is a system thing and we don't really need to have a per device setting. Let's deal with this when we really have an use case for that.
The above is one of the reasons why I would likely go with a build option. ATM, this is kind of a system level decision and the build option would be the simpler approach for that. But as I said, I guess I can live with the env var (even though that brings a runtime penalty - but not when streaming at least).
Unfortunately, there's no way in the kernel to do that (AFAIK) and I feel it would not be trivial to abstract what every device needs in terms of DMA mappings (and it would be for sure time consuming). We know we have users needing something like this so I feel this PR is a good compromise (As I said, I was also not convinced with what we previously had). And as I said before, this is really no different than what we already had (I mean, assuming that we always want the "system" heap). |
|
I mean, for peace of mind, @dNechita you can also try to look at some v4l2/media userspace tools in github and search for the dmabuf path . Some of these devices are also using dmabufs so we might see if they are doing something more clever. (if handling this at all in userspace). |
PR Description
"This reverts the functionality that allowed users to change the DMA allocator type through the public API. The use case is niche and rarely needed at present. The existing functionality supported two options: the default 'system' and 'cma,linux'—the latter being non-standard and system-dependent (see #1329), often requiring a custom string. Supporting this through the public API adds unnecessary complexity and risks future breakage. Instead, I am introducing an alternative approach for changing the DMA allocator that avoids impacting the API.
PR Type
PR Checklist