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 B4ACB45CA5 for ; Thu, 7 Nov 2024 10:42:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 845BB42ED3; Thu, 7 Nov 2024 10:42:31 +0100 (CET) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by mails.dpdk.org (Postfix) with ESMTP id 38BB742E86 for ; Thu, 7 Nov 2024 10:42:30 +0100 (CET) Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-539fb49c64aso970165e87.0 for ; Thu, 07 Nov 2024 01:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730972549; x=1731577349; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=kiqxzX6ChGg3ZY1JblJOYa7SCOCZPRrZfb39+BVVL1U=; b=jJD0RSZvL1LU360NIBkaQsQp7IY/CoRp+GkmBf771d2RVPeKXgCOGYq+V/QcQ4edSQ LyGE+orsyCxk1CaUkjBdmbC87tPaCRyHdJCIic7iM1wFfu1hPZo6kHmD48eSv6fuMhMH UTSsRiJK2VMeg11sZ2PHA4/VaXEBKX6V0pk1vNJYqFf16ZyPkAzqyFrYReCQhQGVOFKY gdmsNzjmPxJZP0HuoRqoeyPCvH5+jPRj0nhAYYdnb7sITjhY2w3HMV+hnwyQFFAPVU6W dfnZyQrjOjgI0dRUJsb+7DTPTpL69LzwTqojfh7udZ23vnTYZmEP0KjbXl6FurY2O65F qs+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730972549; x=1731577349; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kiqxzX6ChGg3ZY1JblJOYa7SCOCZPRrZfb39+BVVL1U=; b=gLbv+DIl5JVeDpIbKA/5iMJXD1KGYKG3oYohLbDyfcH1DCHNNN4mxTPncEHwCzCftF npSY1rDjCpNyCRWxC0Wgl1CkH8NMo49rvYU4qDAPxSItHpjAV7b0CGz4jQ3IStAPu1u+ XUsjCXDoiXuFdUHRQMkwGBV8Pyk2r/YFkqYOX3M/9not37/PkHxE7xA44wn6Em+r8Aav SHpObO9q6Fds7dB5zYHAfLjDQqQ2vO15YzlFxU7tXLq9fuQiUM70OMF0DGI8R96bXQ4V fjRh+3WPkfCXuRekwlGuHR7rqzTM94Y75K69i0K1ZzqvElt/xsI59Z9I7/9Kp6c0RDyC vJrg== X-Gm-Message-State: AOJu0YwxveCKvmTna7I5PDINEzvv4mGqE4ST/4rpKHzfbPnlSwQXIGtn N4aN5s6L44KkSFPjgViwhTBR4ohnjcEodG0NLnCtUgoE2QwMPEig X-Google-Smtp-Source: AGHT+IHBgN6/RxqLUN+etwQYfGScYHGK8ue//62USQ0swXKhCQdDn3p8OpVLSqEg/P5A3d7N3WuVug== X-Received: by 2002:a05:6512:32c8:b0:53b:1fea:baa9 with SMTP id 2adb3069b0e04-53d65dca657mr18626472e87.8.1730972549204; Thu, 07 Nov 2024 01:42:29 -0800 (PST) Received: from sovereign (broadband-109-173-43-194.ip.moscow.rt.ru. [109.173.43.194]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-53d826a9d0asm145109e87.183.2024.11.07.01.42.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Nov 2024 01:42:27 -0800 (PST) Date: Thu, 7 Nov 2024 12:42:25 +0300 From: Dmitry Kozlyuk To: "Wieckowski, Jacob" Cc: "users@dpdk.org" Subject: Re: DMA Transfers to PCIe Bar Memory Message-ID: <20241107124225.50c22ee2@sovereign> In-Reply-To: References: <20241106204604.444529d5@sovereign> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org 2024-11-07 09:16 (UTC+0000), Wieckowski, Jacob: > Hi Dimitry, >=20 > thank you for the quick response. >=20 > Ok, DMA in the classic sense is not possible. > > However, if you carry out a write transfer into the BAR memory from DPDK,= then, as I understand it, this access should be divided into several small= postage-compliant TLP packets with a maximum payload size as specified in = config space.=20 >=20 > Can block transfers in sizes of 512 bytes be carried out with the rte mem= cpy? The DPDK API states that the AVX-512 memcpy parameter must be enabled = for x86 platforms. >=20 > Do other special precautions have to be taken in the DPDK environment to = setup this kind of transfer? Could you please start with the problem you're solving? DPDK uses DMA internally (mainly) to transfer packet data from/to HW. It puts physical address of the buffer, etc. to NIC queue descriptor, writes to a doorbell register, then the NIC DMA-writes/reads the buffer; PCI transfer sizes are probably selected by HW. All of this is within PMD (userspace drivers), no API is exposed. rte_memcpy() is intended for copy from RAM to RAM. You can Cc: Morten Br=C3=B8rup probably, but I doubt that rte_memcpy() is specialized for DMA in any way. The buffer may be filled with rte_mempcy() by application, but this is done before handling the buffer to PMD, and thus before DMA. Are you looking for functionality of "dmadev" library? https://doc.dpdk.org/guides/prog_guide/dmadev.html