[dpdk-dev] Windows Draft Build
Hi, I'm having trouble building "dpdk.sln" from "windpdk-v18.08-clang" branch of "dpdk-draft-windows" repository using Visual Studio 2019 Community Edition. All projects are set up to use some "llvm" toolset. If I install LLVM Build Tools and switch toolset to Clang-cl, build fails because Platform SDK is not accessible. I tried to add Platform SDK include paths to Additional Include Directories, but ended up with multiple errors, indicating incompatibilities between Windows headers and Clang. Please find screenshots and logs attached. "Netuio.sln" builds OK. -- Dmitry Kozlyuk 1>-- Rebuild All started: Project: librte_kvargs, Configuration: Debug x64 -- 1>In file included from :1: 1>Z:\mk\exec-env\windows\..\..\..\lib\librte_eal\windows\rte_override\rte_windows.h(26,10): warning : non-portable path to file ''; specified path differs in case from file name on disk [-Wnonportable-include-path] 1>In file included from :1: 1>In file included from Z:\mk\exec-env\windows\..\..\..\lib\librte_eal\windows\rte_override\rte_windows.h:26: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\windows.h:171: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\windef.h:24: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\minwindef.h:182: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h:105: 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\kernelspecs.h(36,10): warning : non-portable path to file '"driverspecs.h"'; specified path differs in case from file name on disk [-Wnonportable-include-path] 1>In file included from :1: 1>In file included from Z:\mk\exec-env\windows\..\..\..\lib\librte_eal\windows\rte_override\rte_windows.h:26: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\windows.h:171: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\windef.h:24: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\minwindef.h:182: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h:198: 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\basetsd.h(322,12): warning : cast to 'void * __ptr32' from smaller integer type 'unsigned long' [-Wint-to-void-pointer-cast] 1>In file included from :1: 1>In file included from Z:\mk\exec-env\windows\..\..\..\lib\librte_eal\windows\rte_override\rte_windows.h:26: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\windows.h:171: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\windef.h:24: 1>In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\minwindef.h:182: 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h(2487,1): error : '__C_ASSERT__' declared as an array with a negative size 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h(193,47): message : expanded from macro 'C_ASSERT' 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h(3245,19): warning : '__cpuidex' is not a recognized builtin; consider including to access non-builtin intrinsics [-Wignored-pragma-intrinsic] 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h(3350,19): warning : '_m_prefetchw' is not a recognized builtin; consider including to access non-builtin intrinsics [-Wignored-pragma-intrinsic] 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h(3398,19): warning : '__getcallerseflags' is not a recognized builtin; consider including to access non-builtin intrinsics [-Wignored-pragma-intrinsic] 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h(3411,19): warning : '__segmentlimit' is not a recognized builtin; consider including to access non-builtin intrinsics [-Wignored-pragma-intrinsic] 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h(3424,19): warning : '__readpmc' is not a recognized builtin; consider including to access non-builtin intrinsics [-Wignored-pragma-intrinsic] 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h(3471,19): warning : '__movsb' is not a recognized builtin; consider including to access non-builtin intrinsics [-Wignored-pragma-intrinsic] 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h(3472,19): warning : '__movsw' is not a recognized builtin; consider including to access non-builtin intrinsics [-Wignored-pragma-intrinsic] 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winnt.h(3473,19): warning : '__movsd' is not a recognized builtin; consider including to access non-builtin intrinsics [-Wignored-pragma-intrinsic] 1>C:\Program Files (x86)\Windows Kits\10\I
[dpdk-dev] [PATCH v3] net/i40e: relaxed barrier in the tx fastpath
To keep ordering of mixed accesses, rte_cio is sufficient. The rte_io barrier is overkill.[1] [1] http://inbox.dpdk.org/dev/CALBAE1M-ezVWCjqCZDBw+MMDEC4O9 qf0kpn89emdgdajepk...@mail.gmail.com Signed-off-by: Gavin Hu --- V3: - optimize the barriers in the fast path only, leave as it is for the barriers in the slow path and control path - drop the virtio patches from the list as they are in the control path - it makes more sense to relax the barrier in the fast path, at the PMD level. relaxing the fundamental rte_io_x barriers APIs requires scrutinizations for each PMDs which use the barriers directly or indirectly. V2: - remove virtio_pci_read/write64 APIs definitions, they are not needed and generate compiling errors like " error: unused function 'virtio_pci_write64' [-Werror,-Wunused-function]" - update the reference link to kernel source code --- drivers/net/i40e/i40e_rxtx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c index fd1ae80da..8c0f7cc67 100644 --- a/drivers/net/i40e/i40e_rxtx.c +++ b/drivers/net/i40e/i40e_rxtx.c @@ -1248,7 +1248,8 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts) (unsigned) txq->port_id, (unsigned) txq->queue_id, (unsigned) tx_id, (unsigned) nb_tx); - I40E_PCI_REG_WRITE(txq->qtx_tail, tx_id); + rte_cio_wmb(); + I40E_PCI_REG_WRITE_RELAXED(txq->qtx_tail, tx_id); txq->tx_tail = tx_id; return nb_tx; -- 2.17.1
Re: [dpdk-dev] Windows Support Plan
> The main reason DPDK memory management works the way it does is because > of need to support multiprocess. In order to map memory in all > processes, we need that space reserved (otherwise there's no guarantee > that the newly mapped memory segment will be mapped in all processes, > and it'll cause runtime failure). If it wasn't for that, we could > allocate memory arbitrarily and as needed. Windows should either follow > this model, or drop secondary support and go its own way - the internals > are OS-specific anyway. I think Windows should support multi-process, because there is a demand and an ongoing design effort for multi-tenancy and resource arbitration [0]. Until Windows kernel implements "secure API" for the architecture proposed by [0] (if it does at all), DPDK multi-process model can to some point support the features desired. For example, a primary process may be a service performing resource arbitration for applications being secondary processes. > Bear in mind that DPDK also supports external memory, you might > need to make some allowances for that too. I haven't considered external memory yet. Does it need anything beyond mapping VA to IOVA? > As for IOMMU - we don't support IOVA as VA addressing on FreeBSD, so if > Windows port can only work with IOVA as PA, that's fine too. The > question of IOVA mode really boils down to, do we control the DMA > addresses (IOVA as VA mode), or does the system (IOVA as PA). I'm not > familiar with how IOMMU works on Windows, but as long as it fits into > that model and we keep the API, it should also be OK :) AFAIK, Windows doesn't expose IOMMU either to applications or drivers. Do I understand correctly that implies only IOVA as PA can be supported, because mappings can't be set up? The trouble is, PA cannot generally be used if IOMMU is present, but there is no way to tell if it is. Windows kernel offers API to allocate buffers for DMA [1], but MM doesn't know if it allocates memory for DMA or not, even if that kernel API would be exposed. If I got it right, DPDK just can't be used on Windows with IOMMU enabled (can't tell for VMs that don't see IOMMU). [0]: https://www.dpdk.org/wp-content/uploads/sites/35/2018/12/RMenonOCardona_Improving-Security-in-Windows-DPDK.pdf [1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nc-wdm-pallocate_common_buffer_ex -- Dmitry Kozlyuk
