Hi Morten,

That's *exactly* how this architecture is designed & implemented.

The DMA configuration and initialization is up to the application (OVS).
The VHost library is passed the DMA-dev ID, and its new async rx/tx APIs, and uses the DMA device to accelerate the copy.

Looking forward to talking on the call that just started. Regards, -Harry

From: Morten Brørup <mb@smartsharesystems.com>
Sent: Tuesday, March 29, 2022 1:51 PM
To: Pai G, Sunil <sunil.pai.g@intel.com>; Stokes, Ian <ian.stokes@intel.com>; Hu, Jiayu <jiayu.hu@intel.com>; Ferriter, Cian <cian.ferriter@intel.com>; Van Haaren, Harry <harry.van.haaren@intel.com>; Ilya Maximets <i.maximets@ovn.org>; maxime.coquelin@redhat.com; ovs-dev@openvswitch.org; dev@dpdk.org
Cc: Mcnamara, John <john.mcnamara@intel.com>; O'Driscoll, Tim <tim.odriscoll@intel.com>; Finn, Emma <emma.finn@intel.com>
Subject: RE: OVS DPDK DMA-Dev library/Design Discussion

Having thought more about it, I think that a completely different architectural approach is required:

Many of the DPDK Ethernet PMDs implement a variety of RX and TX packet burst functions, each optimized for different CPU vector instruction sets. The availability of a DMA engine should be treated the same way. So I suggest that PMDs copying packet contents, e.g. memif, pcap, vmxnet3, should implement DMA optimized RX and TX packet burst functions.

Similarly for the DPDK vhost library.

In such an architecture, it would be the application’s job to allocate DMA channels and assign them to the specific PMDs that should use them. But the actual use of the DMA channels would move down below the application and into the DPDK PMDs and libraries.

Med venlig hilsen / Kind regards,

-Morten Brørup

From: Pai G, Sunil [mailto:sunil.pai.g@intel.com]
Sent: Monday, 28 March 2022 20.19
To: Stokes, Ian; Hu, Jiayu; Ferriter, Cian; Van Haaren, Harry; Ilya Maximets; Maxime Coquelin (maxime.coquelin@redhat.com); ovs-dev@openvswitch.org; dev@dpdk.org
Cc: Mcnamara, John; O'Driscoll, Tim; Finn, Emma
Subject: RE: OVS DPDK DMA-Dev library/Design Discussion

Hi All,

Please see below PDF which will be presented in the call.

https://github.com/Sunil-Pai-G/OVS-DPDK-presentation-share/blob/main/OVS%20vhost%20async%20datapath%20design%202022%20session%202.pdf

Thanks and Regards,

Sunil

-----Original Appointment-----
From: Stokes, Ian <ian.stokes@intel.com>
Sent: Thursday, March 24, 2022 9:07 PM
To: Pai G, Sunil; Hu, Jiayu; Ferriter, Cian; Van Haaren, Harry; Ilya Maximets; Maxime Coquelin (maxime.coquelin@redhat.com); ovs-dev@openvswitch.org; dev@dpdk.org
Cc: Mcnamara, John; O'Driscoll, Tim; Finn, Emma
Subject: OVS DPDK DMA-Dev library/Design Discussion
When: Tuesday, March 29, 2022 2:00 PM-3:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London.
Where: Google Meet

Hi All,

This meeting is a follow up to the call earlier this week.

This week Sunil presented 3 different approaches to integrating DMA-Dev with OVS along with the performance impacts.

https://github.com/Sunil-Pai-G/OVS-DPDK-presentation-share/blob/main/OVS%20vhost%20async%20datapath%20design%202022.pdf

The approaches were as follows:

· Defer work.

· Tx completions from Rx context.

· Tx completions from Rx context + lockless ring.

The pros and cons of each approach were discussed but there was no clear solution reached.

As such a follow up call was suggested to continue discussion and to reach a clear decision on the approach to take.

Please see agenda as it stands below:

Agenda

· Opens

· Continue discussion of 3x approaches from last week (Defer work, “V3”, V4, links to patches in Sunil’s slides above)

· Design Feedback (please review solutions of above & slide-deck from last week before call to be informed)

· Dynamic Allocation of DMA engine per queue

· Code Availability (DPDK GitHub, OVS GitHub branches)

Please feel free to respond with any other items to be added to the agenda.

Google Meet: https://meet.google.com/hme-pygf-bfb

Regards

Ian