Le jeudi 17 novembre 2022 à 13:10 +0100, Christian König a écrit : > > > DMA-Buf let's the exporter setup the DMA addresses the importer uses to > > > be able to directly decided where a certain operation should go. E.g. we > > > have cases where for example a P2P write doesn't even go to memory, but > > > rather a doorbell BAR to trigger another operation. Throwing in CPU > > > round trips for explicit ownership transfer completely breaks that > > > concept. > > It sounds like we should have a dma_dev_is_coherent_with_dev() which > > accepts two (or an array?) of devices and tells the caller whether the > > devices need explicit ownership transfer. > > No, exactly that's the concept I'm pushing back on very hard here. > > In other words explicit ownership transfer is not something we would > want as requirement in the framework, cause otherwise we break tons of > use cases which require concurrent access to the underlying buffer. I'm not pushing for this solution, but really felt the need to correct you here. I have quite some experience with ownership transfer mechanism, as this is how GStreamer framework works since 2000. Concurrent access is a really common use cases and it is quite well defined in that context. The bracketing system (in this case called map() unmap(), with flag stating the usage intention like reads and write) is combined the the refcount. The basic rules are simple: - An object with a refcount higher then 2 is shared, hence read-only - An object with refcount of one, mapped for writes becomes exclusive - Non exclusive writes can be done, but that has to be explicit (intentional), we didn't go as far as Rust in that domain - Wrappers around these object can use mechanism like "copy-on-write" and can also maintain the state of shadow buffers (e.g. GL upload slow cases) even with concurrent access. Just hope it clarify, Rust language works, yet its all based on explicit ownership transfers. Its not limiting, but it requires a different way of thinking how data is to be accessed. Nicolas
