From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 07CF4A0506; Tue, 29 Mar 2022 16:44:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AD32540691; Tue, 29 Mar 2022 16:44:15 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 41FE840141 for ; Tue, 29 Mar 2022 16:44:14 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: OVS DPDK DMA-Dev library/Design Discussion Date: Tue, 29 Mar 2022 16:44:12 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86F7D@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OVS DPDK DMA-Dev library/Design Discussion Thread-Index: Adg/jDNGcC8G4wWtSxeVfUOuAS3Y6wACLuFQAM6falAAJoZBIAAA0srQAAK2F/A= References: <98CBD80474FA8B44BF855DF32C47DC35D86F7C@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Van Haaren, Harry" , "Pai G, Sunil" , "Stokes, Ian" , "Hu, Jiayu" , "Ferriter, Cian" , "Ilya Maximets" , , , Cc: "Mcnamara, John" , "O'Driscoll, Tim" , "Finn, Emma" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Van Haaren, Harry [mailto:harry.van.haaren@intel.com]=20 > Sent: Tuesday, 29 March 2022 15.02 >=20 > > From: Morten Br=F8rup =20 > > Sent: Tuesday, March 29, 2022 1:51 PM > >=20 > > Having thought more about it, I think that a completely different = architectural approach is required: > >=20 > > 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. > >=20 > > Similarly for the DPDK vhost library. > >=20 > > 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. > >=20 > >=20 > > Med venlig hilsen / Kind regards, > > -Morten Br=F8rup >=20 > Hi Morten, >=20 > That's *exactly* how this architecture is designed & implemented. > 1. The DMA configuration and initialization is up to the application = (OVS). > 2. 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. >=20 > Looking forward to talking on the call that just started. Regards, = -Harry >=20 OK, thanks - as I said on the call, I haven't looked at the patches. Then, I suppose that the TX completions can be handled in the TX = function, and the RX completions can be handled in the RX function, just = like the Ethdev PMDs handle packet descriptors: TX_Burst(tx_packet_array): 1. Clean up descriptors processed by the NIC chip. --> Process TX DMA = channel completions. (Effectively, the 2nd pipeline stage.) 2. Pass on the tx_packet_array to the NIC chip descriptors. --> Pass on = the tx_packet_array to the TX DMA channel. (Effectively, the 1st = pipeline stage.) RX_burst(rx_packet_array): 1. Pass on the finished NIC chip RX descriptors to the rx_packet_array. = --> Process RX DMA channel completions. (Effectively, the 2nd pipeline = stage.) 2. Replenish NIC chip RX descriptors. --> Start RX DMA channel for any = waiting packets. (Effectively, the 1nd pipeline stage.) PMD_init(): - Prepare NIC chip RX descriptors. (In other words: Replenish NIC chip = RX descriptors. =3D RX pipeline stage 1.) PS: Rearranged the email, so we can avoid top posting.