On Fri, Oct 27, 2023 at 7:16 PM Medvedkin, Vladimir <vladimir.medved...@intel.com> wrote: > > Hi Satananda, Anoob, Chengwen, Jerin, all, > > After a number of internal discussions we have decided that we're going > to postpone this feature/patchset till next release. > > >[Satananda] Have you considered extending rte_dma_port_param and > rte_dma_vchan_conf to represent interdomain memory transfer setup as a > separate port type like RTE_DMA_PORT_INTER_DOMAIN ? > > >[Anoob] Can we move this 'src_handle' and 'dst_handle' registration to > rte_dma_vchan_setup so that the 'src_handle' and 'dst_handle' can be > configured in control path and the existing datapath APIs can work as is. > > >[Jerin] Or move src_handle/dst_hanel to vchan config > > We've listened to feedback on implementation, and have prototyped a > vchan-based interface. This has a number of advantages and > disadvantages, both in terms of API usage and in terms of our specific > driver. > > Setting up inter-domain operations as separate vchans allow us to store > data inside the PMD and not duplicate any API paths, so having multiple > vchans addresses that problem. However, this also means that any new > vchans added while the PMD is active (such as attaching to a new
This could be mitigated by setup max number of vchan up front before start() and use as demanded. > process) will have to be gated by start/stop. This is probably fine from > API point of view, but a hassle for user (previously, we could've just > started using the new inter-domain handle right away). > > Another usability issue with multiple vchan approach is that now, each > vchan will have its own enqueue/submit/completion cycle, so any use case > relying on one thread communicating with many processes will have to > process each vchan separately, instead of everything going into one > vchan - again, looks fine API-wise, but a hassle for the user, since > this requires calling submit and completion for each vchan, and in some > cases it requires maintaining some kind of reordering queue. (On the > other hand, it would be much easier to separate operations intended for > different processes with this approach, so perhaps this is not such a > big issue) IMO, The design principle behind vchan was, -A single HW queue be serving N number of vchan -A vchan is nothing, but it creates desired HW instruction format as template in slow path to use in fast path or write some slow path registers to define the attribute of vchan. IMO, The above-mentioned usability constraints will be there in all PMD as vchan is muxing a single HW queue. IMO, Decision for vchan vs fast path API could be a) Number of vchan is required - In this case, we are using for VM to VM or Container to Container copy. So I think, it is limited b) HW support - Some HW's in order to reduce size of HW descriptor size, some features will be configured as slow path only(can not be changed at runtime, without reconfiguring the vchan).
