summaryrefslogtreecommitdiff
path: root/datapath-windows/ovsext/User.h
Commit message (Collapse)AuthorAgeFilesLines
* datapath-windows: Add IPv6 Geneve tunnel support in WindowsWilson Peng2022-04-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the first step OVS Windows will support IPv6 tunnel(Geneve IPv6 tunnel). Implementation on Windows ------------------------- 1. For the IPv6 tunnel support,  OvsIPTunnelKey will replace original OvsIPv4TunnelKey in the related flow context handing. 2. The related src and dst address will be  changed to SOCKADDR_INET type from UINT32. 3. For the IPv6 tunnel,  one node running OVS-Windows could encapsulate IPv4/IPv6 Packets via IPV6 Geneve Tunnel, and the node could also encapsulate IPv4/IPv6 packet Via IPv4 Geneve tunnel. 4. Related IPHelper data structure will be adapted to support IPv6 Tunnel. In the IPHelper part the related Windows API(such as GetUnicastIpAddressTable/GetBestRoute2/GetIpNetEntry2/ ResolveIpNetEntry2) and Windows data structure(MIB_IPFORWARD_ROW2/MIB_IPNET_ROW2/IP_ADDRESS_PREFIX) Have already supported both IPv4 and IPV6. Now OVS Windows has been adjusted some functions And data structured to support IPV6 tunnel also. 5. OVS_TUNNEL_KEY_ATTR_IPV6_SRC and OVS_TUNNEL_KEY_ATTR_IPV6_DST filed will be supported in OVS-Windows kernel for IPV6 tunnel. Testing done. ------------------------- Related topo, 1 Windows VM(Win2019) and 2 Ubuntu 16.04 server. Both VMs Are running on one ESX host. 1. Setup one IPV6 Geneve Tunnel between 1 Windows VM and 1 Ubuntu server. Windows VM, vif0( 6000::2/40.1.1.10) vif1(5000::2)—— Ubuntu VM Eth2(5000::9), name space ns1 with interface ns1_link_peer(6000::9/40.1.1.2) Related tunnnel, ovs-vsctl.exe add-port br-int bms-tun0 -- set interface bms-tun0 type=Geneve options:csum=true options:key=flow options:local_ip="5000::2" options:remote_ip=flow In this topo, traffic from Vif0(Win) to ns1_link_peer(Ubuntu) will be gone through the Geneve tunnel (5000::2—>5000::9) for both IPv4 traffic(40.1.1.10-->40.1.1.2) and IPv6 traffic(6000::2—>6000::9) 2. Setup one IPV4 Geneve Tunnel between Windows VM and 1 Ubuntu server. Windows VM, vif0( 6000::2/40.1.1.10) vif1(50.1.1.11)—— Ubuntu, Eth2(50.1.1.9), name space ns1 with interface ns1_link_peer(6000::19/40.1.1.9) Related tunnnel, ovs-vsctl.exe -- set Interface bms-tun0 type=geneve options:csum=true options:key=flow options:local_ip="50.1.1.11" options:remote_ip=flow In this topo, traffic from Vif0(Win) to ns1_link_peer(Ubuntu) will be gone through the Geneve Tunnel (50.1.1.11—>50.1.1.9) for both IPv4 traffic(40.1.1.10-->40.1.1.9) and IPv6 traffic(6000::2—>6000::19). 3.Regression test for IpV4 in Antrea project (about 60 test case) is PASS Future Work ----------- Add other type IPv6 tunnel support for Gre/Vxlan/Stt. Signed-off-by: Wilson Peng <pweisong@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Append tunnel info to upcall for correct templateAmber Hu via dev2020-02-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Formerly, there is no tunnel information appended in the upcall’s packet data, which is expected by IPFIX in userspace to calculate the template for exporting the sampled flow record of on egress tunnel port. To fix this, during performing OvsOutputUserspaceAction(), we would check whether it is initiated by the sampling on egress tunnel which would be indicated by the attribute as OVS_USERSPACE_ATTR_EGRESS_TUN_PORT in the nested attribute list. If so, we would append the tunKey in OvsForwardingContext indexed by OVS_PACKET_ATTR_EGRESS_TUN_KEY to the upcall. Besides, at this point, the source transport port and source ip address are not available in the structure, so we have to fill it in the way how the packet would be capsulated during performing OvsEncapGeneve(), which is following the OvsOutputUserspaceAction() unfortunately. I have tested the IPFIX functionality with the change, we could see the template is correct and the expected tunnel information could be packed in the IPFIX packet finally. The traffic for test is generated by PING utility. >From d727d051c9a44a4a93e5ee5f3da3ca9b125aad29 Mon Sep 17 00:00:00 2001 From: Amber Hu <qhu@vmware.com> Date: Thu, 30 Jan 2020 18:01:32 -0800 Subject: [PATCH v3] datapath-windows: Append tunnel info to upcall for correct template Signed-off-by: Amber Hu <qhu@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: move packet read code to User.cNithin Raju2015-09-291-0/+7
| | | | | | | | | Simple code motion. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Avoid unnecessary vport array searchSorin Vinturis2015-09-291-2/+3
| | | | | | Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Refactor CreateQueue function to handle vport pid.Ankur Sharma2014-10-241-2/+2
| | | | | | | | | Refactored CreateQueue function so that packets are enqueued to correct corresponding queue. Signed-off-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: pid-instance hash table APIs.Ankur Sharma2014-10-241-0/+10
| | | | | | | | | In this patch we have added APIs for insert, delete and search APIs. Signed-off-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
* datapath-windows: Fixes during integration testing.Ankur Sharma2014-10-231-1/+1
| | | | | | | Signed-off-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Sorin Vinturis <svinturis@cloudbasesolutions.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Packet subscribe handlerEitan Eliahu2014-10-171-12/+8
| | | | | | | | | | | | | This change includes the following: [1] Handler for subscribe/unsubscribe to a packet queue associated with a socket pid. [2] Allocation of per socket packet queue on a packet subscription. [3] Removal of static allocated queues. [4] Freeing the packet queue (on user mode process termination). Signed-off-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: changes to existing PACKET_CMD handler.Ankur Sharma2014-10-151-3/+1
| | | | | | | | | | | | | | | | | | In this patch we have made following changes: OvsPacketExecute => Changed the data structure to have packet and actions as pointer (instead of zero length array). It is done because we will not do memcpy of packet now, pointer will just point to corresponding offset in input buffer. OvsExecuteDpIoctl => We only need input buffer now. Hence Changed the function signature. Signed-off-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: OVS_PACKET_CMD_EXECUTE command handler.Ankur Sharma2014-10-151-0/+5
| | | | | | | | | | In this patch we cover the basic registeration of OVS_PACKET_CMD_EXECUTE command handler. Signed-off-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Upcall NL packet format: Call NL missed packet functionEitan Eliahu2014-10-151-12/+10
| | | | | | | | | | Remove hard coded queue is, pass the key rather the tunnel key, Remove the none NL implementation Signed-off-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Rename files.Samuel Ghinet2014-08-291-0/+114
This patch includes the file renaming and accommodations needed for the file renaming to build the forwarding extension for Hyper-V. This patch is also a follow-up for the thread: http://openvswitch.org/pipermail/dev/2014-August/044005.html Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>