On Thu, 7 Nov 2024 13:09:41 +0000 "Wieckowski, Jacob" <jacob.wieckow...@vector.com> wrote:
> Hi Jacob, > > 2024-11-07 11:50 (UTC+0000), Wieckowski, Jacob: > > Hi Dimitry, > > > > I am sorry, I was a bit too far ahead with my thoughts. > > > > We have started a DPDK evaluation project to build knowledge and > > understanding of the DPDK framework. > > We used an E1000 driver with a workaround to gain access to the PCIe 5.0 > > R-Tile on the Intel Agilex7 FPGA under Windows. > > > > Accesses to the PCIe BAR work in principle, but we can currently only carry > > out 64-bit accesses to the BAR memory. > > In the PCIe Config Space in the Capabilities Register, a maximum payload > > size of 512 bytes is configured. > > The Intel Core in the FPGA and the Root Complex also support TLPs of this > > length. > > > > We use the rte_read32 and rte_write32 functions to access the bar memory, > > which obviously executes accesses with max 2 DWs. > > We were able to trigger this in the FPGA because only TLP with length 2 > > arrived on the RX Interface. > > > > How can a block transfer be initiated in DPDK so that TLPs with a length of > > 128 DWs are generated on the PCIe Bus? > > Thanks, now I understand what you need. > Unfortunately DPDK has no relevant API; rte_read**() is for small registers. > Maybe there's some useful code in "drivers/raw", but this area is completely > unknown to me, sorry. > Try replying with what you wrote above to the thread in users@dpdk.org and > Cc: Intel people from MAINTAINERS file responsible for "drivers/raw". In general, direct access to PCI by applications is discouraged. All PCI access should be in driver code. What you describe is a bug in the E1000 driver, and should fixed there.
