Re: [ovs-dev] [PATCH] RFC: netdev-dpdk: Add Windows support.

2021-11-04 Thread William Tu
On Thu, Nov 4, 2021 at 4:35 AM Thomas Monjalon  wrote:
>
> 06/10/2021 19:00, William Tu:
> > The patch adds OVS-DPDK supports on Windows.
> [...]
> > Implementation on Windows
> > -
> > It's harder than I thought due to my Linux only background.
> > Sergey and I first need to add meson build support to OVS, in order
> > to make compiling and linking to Windows DPDK library easier[2].
> > In this patch, we use clang compiler on Windows to compile DPDK and
> > OVS, and OVS links to DPDK static library (Dynamic lib still not
> > supported yet in DPDK Windows).
> >
> > Windows DPDK library hasn't finished all its library/driver porting
> > to Windows. So a couple of DPDK library code used by OVS doesn't
> > compile. For examples:
> >   1) ovs-numa.c: used to detect lcores used by DPDK.
> >   2) open_memstream, fopencookies: used to redirect DPDK logs.
> >   3) vhostuser doesn't support: used to connect VM/container.
> >   4) dpdk-socket-mem not support: configuration
> > I simply remove them in this patch.
> > In the future, I will probably refactor or #ifdef.
>
> Yes please, removing code is clearly not the right direction :)
>
> [...]
> > Future Work
> > ---
> > In priority ordering
> > a. Add CI or Dockerfile for building the code
> > b. Performance numbers, compared with OVS kernel datapath
> > c. Try rte_flow HW offload on Windows
> > d. Resolve all the compiler warnings
> > e. Refactor the vhostuser code
> >
> > Some thoughts:
> > f. With clang support on Windows, can we remove MSVC?
> >so OVS will have less compiler-specific code, ex:
> >include\openvswitch\compiler.h
> > g. DPDK starts to implement pthread in Windows, can
> >OVS uses pthread library from DPDK, instead of pthreads4w?
>
> The thread API is not ready yet in DPDK.
> What would be the benefit for OVS to use the same pthread layer as DPDK?
> OVS needs to be able to compile without DPDK.

Hi Thomas,

Yes, you're right.
I was thinking about copying the pthread code from DPDK to OVS code base.
This removes the dependencies on pthreads4w.

I'm working on the RFC v2 patch, will send out this week.

Thanks for all the feedback!
William
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] RFC: netdev-dpdk: Add Windows support.

2021-11-04 Thread Thomas Monjalon
06/10/2021 19:00, William Tu:
> The patch adds OVS-DPDK supports on Windows.
[...]
> Implementation on Windows
> -
> It's harder than I thought due to my Linux only background.
> Sergey and I first need to add meson build support to OVS, in order
> to make compiling and linking to Windows DPDK library easier[2].
> In this patch, we use clang compiler on Windows to compile DPDK and
> OVS, and OVS links to DPDK static library (Dynamic lib still not
> supported yet in DPDK Windows).
> 
> Windows DPDK library hasn't finished all its library/driver porting
> to Windows. So a couple of DPDK library code used by OVS doesn't
> compile. For examples:
>   1) ovs-numa.c: used to detect lcores used by DPDK.
>   2) open_memstream, fopencookies: used to redirect DPDK logs.
>   3) vhostuser doesn't support: used to connect VM/container.
>   4) dpdk-socket-mem not support: configuration
> I simply remove them in this patch.
> In the future, I will probably refactor or #ifdef.

Yes please, removing code is clearly not the right direction :)

[...]
> Future Work
> ---
> In priority ordering
> a. Add CI or Dockerfile for building the code
> b. Performance numbers, compared with OVS kernel datapath
> c. Try rte_flow HW offload on Windows
> d. Resolve all the compiler warnings
> e. Refactor the vhostuser code
> 
> Some thoughts:
> f. With clang support on Windows, can we remove MSVC?
>so OVS will have less compiler-specific code, ex:
>include\openvswitch\compiler.h
> g. DPDK starts to implement pthread in Windows, can
>OVS uses pthread library from DPDK, instead of pthreads4w?

The thread API is not ready yet in DPDK.
What would be the benefit for OVS to use the same pthread layer as DPDK?
OVS needs to be able to compile without DPDK.

> h. Mingw/msys is pretty slow, by switching to meson+clang,
>what's the improvement of build process?
> f. How does OVS-DPDK connect to VM/Container in Windows?
>There is no vhostuser, we should look at netvsc/vmbus.
> 
> I got lots of help from many people in DPDK community, thanks!


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] RFC: netdev-dpdk: Add Windows support.

2021-10-06 Thread Ben Pfaff
On Wed, Oct 6, 2021 at 10:01 AM William Tu  wrote:
> The patch adds OVS-DPDK supports on Windows.

Fantastic! I'm happy to see this work in progress. OVS(-DPDK) everywhere!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH] RFC: netdev-dpdk: Add Windows support.

2021-10-06 Thread William Tu
The patch adds OVS-DPDK supports on Windows.

Motivation
--
Currently OVS supports multiple datapath implementations: Linux kernel,
Windows kernel, userspace with OVS-DPDK Linux, and HW offload.
Adding any new feature to OVS datapath requires OS-specific expertise
and usually ends up with feature mismatch, ex: Linux kernel supports
feature A, but Windows does not, and high maintenace cost [1].

It would be great if OVS just uses single datapath across different
platforms, and the datapath is portatble, performant, and easy
to maintain. The natural choice is the dpif-netdev, the usersapce
netdev datapath currently used by OVS-DPDK and AF_XDP, currently
only works on Linux platform.

So the last piece is to make OVS-DPDK runs on Windows. With this work,
the OVS userspace datapath becomes the one runs on Windows/Linux/FreeBSD
and any new datapath feature should naturally work on different OSes.
Performance of userspace datapath should be equal or better to the kernel
datapath, due to the kernel bypass design of DPDK/AF_XDP, and
optimizations in OVS userspace datapath.

OVS also translates its datapath flows into HW offload-capable NICs,
such as Mellanox CX6. With userspace datapath, HW offload works by
using tc-flower (when using AF_XDP netdev) or using rte_flow API,
(when using DPDK netdev). We've tried non-triival OVS actions such as
conntrack or tunnel actions offloaded into Mellanox card.

Moving forward, OVS will have better cross-platform support, better
performance, and easier to maintain. So far I haven't seen any virtual
switch capable of doing all of the above.

Implementation on Windows
-
It's harder than I thought due to my Linux only background.
Sergey and I first need to add meson build support to OVS, in order
to make compiling and linking to Windows DPDK library easier[2].
In this patch, we use clang compiler on Windows to compile DPDK and
OVS, and OVS links to DPDK static library (Dynamic lib still not
supported yet in DPDK Windows).

Windows DPDK library hasn't finished all its library/driver porting
to Windows. So a couple of DPDK library code used by OVS doesn't
compile. For examples:
  1) ovs-numa.c: used to detect lcores used by DPDK.
  2) open_memstream, fopencookies: used to redirect DPDK logs.
  3) vhostuser doesn't support: used to connect VM/container.
  4) dpdk-socket-mem not support: configuration
I simply remove them in this patch.
In the future, I will probably refactor or #ifdef.

In addition, only a few DPDK PMD drivers are supported.
(please check the DPDK doc[3])
  1) Physical: ice, i40e, mlx5, ixgbe
  3) Virtual: none (still work in progress)

For ice, i40, ixgbe, you will need additional two Windows drivers,
netuio and virt2phys. For mlx5, you will need WINOF-2.
I tested this patch using mlx5 pmd on Azure cloud and on-prem
and ixgbevf on AWS EC2, using Windows server 2019.
And I only tested basic OpenFlow actions such as matching ipv4 headers,
drop and output.

Future Work
---
In priority ordering
a. Add CI or Dockerfile for building the code
b. Performance numbers, compared with OVS kernel datapath
c. Try rte_flow HW offload on Windows
d. Resolve all the compiler warnings
e. Refactor the vhostuser code

Some thoughts:
f. With clang support on Windows, can we remove MSVC?
   so OVS will have less compiler-specific code, ex:
   include\openvswitch\compiler.h
g. DPDK starts to implement pthread in Windows, can
   OVS uses pthread library from DPDK, instead of pthreads4w?
h. Mingw/msys is pretty slow, by switching to meson+clang,
   what's the improvement of build process?
f. How does OVS-DPDK connect to VM/Container in Windows?
   There is no vhostuser, we should look at netvsc/vmbus.

I got lots of help from many people in DPDK community, thanks!

Reference
-
[1] https://dl.acm.org/doi/10.1145/3452296.3472914
[2] 
http://patchwork.ozlabs.org/project/openvswitch/cover/20210808014931.320242-1-sergey.madami...@gmail.com/
[3] https://doc.dpdk.org/guides/windows_gsg/
[4] Porting OvS-DPDK to Windows with Meson
https://github.com/smadaminov/ovs-dpdk-meson-issues

Signed-off-by: William Tu 
---
 ovs/config.h.meson |   7 -
 ovs/include/openvswitch/compiler.h |   4 +-
 ovs/include/openvswitch/util.h |   2 +-
 ovs/lib/dpdk.c | 114 +---
 ovs/lib/dpif-netdev.c  |   4 +
 ovs/lib/meson.build|  12 +-
 ovs/lib/netdev-dpdk.c  | 934 +
 ovs/lib/sflow_api.h|   1 +
 ovs/lib/util.c |   4 -
 ovs/lib/vlog.c |   7 +
 ovs/meson.build|  88 ++-
 ovs/meson_options.txt  |   2 +
 ovs/ofproto/meson.build|   3 +
 ovs/ovsdb/meson.build  |   3 +
 ovs/utilities/meson.build  |   3 +
 ovs/vswitchd/meson.build   |  10 +
 ovs/vtep/meson.build   |   3 +
 17 files changed, 140 insertions(+), 1061 deletions(-)

diff --git