{"id":2233254,"url":"http://patchwork.ozlabs.org/api/1.2/patches/2233254/?format=json","web_url":"http://patchwork.ozlabs.org/project/openvswitch/patch/20260505225239.2401918-4-i.maximets@ovn.org/","project":{"id":47,"url":"http://patchwork.ozlabs.org/api/1.2/projects/47/?format=json","name":"Open vSwitch","link_name":"openvswitch","list_id":"ovs-dev.openvswitch.org","list_email":"ovs-dev@openvswitch.org","web_url":"http://openvswitch.org/","scm_url":"git@github.com:openvswitch/ovs.git","webscm_url":"https://github.com/openvswitch/ovs","list_archive_url":"","list_archive_url_format":"","commit_url_format":""},"msgid":"<20260505225239.2401918-4-i.maximets@ovn.org>","list_archive_url":null,"date":"2026-05-05T22:52:12","name":"[ovs-dev,3/5] Documentation: Remove Windows docs.","commit_ref":null,"pull_url":null,"state":"new","archived":false,"hash":"5bbb99a26a80c97dd435d610b3bdc2eebf4d7565","submitter":{"id":76798,"url":"http://patchwork.ozlabs.org/api/1.2/people/76798/?format=json","name":"Ilya Maximets","email":"i.maximets@ovn.org"},"delegate":null,"mbox":"http://patchwork.ozlabs.org/project/openvswitch/patch/20260505225239.2401918-4-i.maximets@ovn.org/mbox/","series":[{"id":502908,"url":"http://patchwork.ozlabs.org/api/1.2/series/502908/?format=json","web_url":"http://patchwork.ozlabs.org/project/openvswitch/list/?series=502908","date":"2026-05-05T22:52:10","name":"Remove Windows support.","version":1,"mbox":"http://patchwork.ozlabs.org/series/502908/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/patches/2233254/comments/","check":"success","checks":"http://patchwork.ozlabs.org/api/patches/2233254/checks/","tags":{},"related":[],"headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","ovs-dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ovs-dev@lists.linuxfoundation.org"],"Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=openvswitch.org\n (client-ip=140.211.166.136; helo=smtp3.osuosl.org;\n envelope-from=ovs-dev-bounces@openvswitch.org; receiver=patchwork.ozlabs.org)","smtp1.osuosl.org;\n dmarc=none (p=none dis=none) header.from=ovn.org"],"Received":["from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g9DMX4Pflz1yJV\n\tfor ; Wed, 06 May 2026 08:53:44 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby smtp3.osuosl.org (Postfix) with ESMTP id 8B92B60BA9;\n\tTue, 5 May 2026 22:53:42 +0000 (UTC)","from smtp3.osuosl.org ([127.0.0.1])\n by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP\n id aVebOlt-lTv1; Tue, 5 May 2026 22:53:39 +0000 (UTC)","from lists.linuxfoundation.org (lf-lists.osuosl.org\n [IPv6:2605:bc80:3010:104::8cd3:938])\n\tby smtp3.osuosl.org (Postfix) with ESMTPS id 9587B60BC2;\n\tTue, 5 May 2026 22:53:39 +0000 (UTC)","from lf-lists.osuosl.org (localhost [127.0.0.1])\n\tby lists.linuxfoundation.org (Postfix) with ESMTP id 704A1C04EB;\n\tTue, 5 May 2026 22:53:39 +0000 (UTC)","from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])\n by lists.linuxfoundation.org (Postfix) with ESMTP id 1CD70C04EB\n for ; Tue, 5 May 2026 22:53:38 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n by smtp1.osuosl.org (Postfix) with ESMTP id D7F8C80F29\n for ; Tue, 5 May 2026 22:53:13 +0000 (UTC)","from smtp1.osuosl.org ([127.0.0.1])\n by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP\n id Cmpy9RbwBsHW for ;\n Tue, 5 May 2026 22:53:09 +0000 (UTC)","from mail-wr1-f67.google.com (mail-wr1-f67.google.com\n [209.85.221.67])\n by smtp1.osuosl.org (Postfix) with ESMTPS id B24018137D\n for ; Tue, 5 May 2026 22:53:08 +0000 (UTC)","by mail-wr1-f67.google.com with SMTP id\n ffacd0b85a97d-44e1860558fso1876514f8f.0\n for ; Tue, 05 May 2026 15:53:08 -0700 (PDT)","from im-t490s (37-48-40-237.nat.epc.tmcz.cz. [37.48.40.237])\n by smtp.gmail.com with ESMTPSA id\n ffacd0b85a97d-45055960811sm8060136f8f.27.2026.05.05.15.53.04\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Tue, 05 May 2026 15:53:05 -0700 (PDT)"],"X-Virus-Scanned":["amavis at osuosl.org","amavis at osuosl.org"],"X-Comment":"SPF check N/A for local connections -\n client-ip=2605:bc80:3010:104::8cd3:938; helo=lists.linuxfoundation.org;\n envelope-from=ovs-dev-bounces@openvswitch.org; receiver= ","DKIM-Filter":["OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9587B60BC2","OpenDKIM Filter v2.11.0 smtp1.osuosl.org B24018137D"],"Received-SPF":"Pass (mailfrom) identity=mailfrom; client-ip=209.85.221.67;\n helo=mail-wr1-f67.google.com; envelope-from=i.maximets.ovn@gmail.com;\n receiver=","DMARC-Filter":"OpenDMARC Filter v1.4.2 smtp1.osuosl.org B24018137D","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1778021587; x=1778626387;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=GdP8wjfOSzuyFqEYXLMSJUpqSM8+jIL9KbupsVVkM2w=;\n b=VaUq5tUz7ApA3c4nyoJaigfY093IegIFXQJtNRKbtUH2TJm6H7n4vfxssOXc/yY1Gc\n nkbMyicK5OAr1m25xkbkIqT2402O80ZNXi4iDkRIect5q1zakmPNrnMexecwqb2tVZlG\n 5Vp3NRxYLYakQmpinUKvV9gjG65lCFCNF0DNcjMiNY6/IRTHku+d+WEttJGrxMjA7oCL\n NvA9Ek5ALuWQBWDV7YUS/Z5oXhoVlW25wt2B8NhADIKPx9LehbcDWfCANwzIzTeMvLNB\n hdrK5+CClZ7pjM0FpB58IXhZaJPsmTnxxHBI9bO4KuDgix6AY+5hWdAxyKWXLSpcl0YT\n oYLA==","X-Gm-Message-State":"AOJu0YxCP+xdUvef6P81AVix2jBqvb3M85nRKJxQmqlDS84eX9SPQv/z\n BCH+hku06qBQ8SN6D9683KdTefppziRq1Nk+lHXcImN37BFgaiq9WPj/eqFlps8B","X-Gm-Gg":"AeBDietMin2kYsq5gKRysW0jTMFbg2r8EsCmQ/CQ6D3qHp1UxsYN4x3Kso83JfqkCJw\n VobllpQJnDYFVRuOeqHNgnBjTffFCo/KVHpzYWJWNyfIFN5cDwCeLAZJlin9X4nJK9bwU1vYNHh\n mTY/7Fh9XLD+vmq9xPHJhSR2kemFY6dvJcoFR0NQpsgeZS3cYOQwCon6ZadPV38l9l+PJRezZ0/\n VK2jVCmQsSaZXAy+BeADP8TH4In+qQ4Jjmap+4+QX4p4adQhpt0XdXv63/veMgVQOrfl0Om8p5X\n kd8/QZVnN77kx1bUTNDUC0bln/2R6wbyQxMSitPaqYfxKoqmKlUmMCRaI4a+M/WWyBZ87+OaQhE\n p265wnMWopJDEckiFW3RMJGT+Nfcthy5HFwNvC4SV3vNYjo0bDQS7Tld6ro4ZhHfth+Tsh+wAWe\n oGX5JwxwaldJKwrSrjmlnljHYa84GDY/IK1rYrdvkYqTEFk3Qf++IENI9fuYoFy1a1Vg==","X-Received":"by 2002:a05:6000:400d:b0:44a:1d55:1e20 with SMTP id\n ffacd0b85a97d-4515b057095mr1406184f8f.5.1778021585750;\n Tue, 05 May 2026 15:53:05 -0700 (PDT)","From":"Ilya Maximets ","To":"ovs-dev@openvswitch.org","Cc":"Ilya Maximets ","Date":"Wed, 6 May 2026 00:52:12 +0200","Message-ID":"<20260505225239.2401918-4-i.maximets@ovn.org>","X-Mailer":"git-send-email 2.53.0","In-Reply-To":"<20260505225239.2401918-1-i.maximets@ovn.org>","References":"<20260505225239.2401918-1-i.maximets@ovn.org>","MIME-Version":"1.0","Subject":"[ovs-dev] [PATCH 3/5] Documentation: Remove Windows docs.","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"ovs-dev-bounces@openvswitch.org","Sender":"\"dev\" "},"content":"Windows support was deprecated in 3.7, it's time to remove it.\nDocumentation is the next self-contained part.\n\nThe next part is the windows-datapath and it's hard to carve out only\nthe datapath-related bits from the docs, so it's easier to remove them\nall together now.\n\nSigned-off-by: Ilya Maximets \n---\n Documentation/automake.mk | 3 -\n Documentation/index.rst | 1 -\n .../contributing/coding-style-windows.rst | 183 ---\n .../internals/contributing/coding-style.rst | 3 +-\n .../internals/contributing/index.rst | 1 -\n Documentation/intro/install/general.rst | 3 -\n Documentation/intro/install/index.rst | 1 -\n Documentation/intro/install/windows.rst | 1080 -----------------\n Documentation/topics/index.rst | 1 -\n Documentation/topics/windows.rst | 509 --------\n 10 files changed, 1 insertion(+), 1784 deletions(-)\n delete mode 100644 Documentation/internals/contributing/coding-style-windows.rst\n delete mode 100644 Documentation/intro/install/windows.rst\n delete mode 100644 Documentation/topics/windows.rst","diff":"diff --git a/Documentation/automake.mk b/Documentation/automake.mk\nindex ea9459b55..23b66a5ee 100644\n--- a/Documentation/automake.mk\n+++ b/Documentation/automake.mk\n@@ -20,7 +20,6 @@ DOC_SOURCE = \\\n \tDocumentation/intro/install/netbsd.rst \\\n \tDocumentation/intro/install/rhel.rst \\\n \tDocumentation/intro/install/userspace.rst \\\n-\tDocumentation/intro/install/windows.rst \\\n \tDocumentation/tutorials/index.rst \\\n \tDocumentation/tutorials/faucet.rst \\\n \tDocumentation/tutorials/ovs-advanced.rst \\\n@@ -61,7 +60,6 @@ DOC_SOURCE = \\\n \tDocumentation/topics/userspace-checksum-offloading.rst \\\n \tDocumentation/topics/userspace-tso.rst \\\n \tDocumentation/topics/userspace-tx-steering.rst \\\n-\tDocumentation/topics/windows.rst \\\n \tDocumentation/howto/index.rst \\\n \tDocumentation/howto/dpdk.rst \\\n \tDocumentation/howto/ipsec.rst \\\n@@ -111,7 +109,6 @@ DOC_SOURCE = \\\n \tDocumentation/internals/contributing/backporting-patches.rst \\\n \tDocumentation/internals/contributing/inclusive-language.rst \\\n \tDocumentation/internals/contributing/coding-style.rst \\\n-\tDocumentation/internals/contributing/coding-style-windows.rst \\\n \tDocumentation/internals/contributing/documentation-style.rst \\\n \tDocumentation/internals/contributing/libopenvswitch-abi.rst \\\n \tDocumentation/internals/contributing/submitting-patches.rst \\\ndiff --git a/Documentation/index.rst b/Documentation/index.rst\nindex 704138473..9f1f9c7f3 100644\n--- a/Documentation/index.rst\n+++ b/Documentation/index.rst\n@@ -45,7 +45,6 @@ Contributing\n - :doc:`internals/contributing/backporting-patches`\n - :doc:`internals/contributing/inclusive-language`\n - :doc:`internals/contributing/coding-style`\n- - :doc:`internals/contributing/coding-style-windows`\n \n Maintaining\n -----------\ndiff --git a/Documentation/internals/contributing/coding-style-windows.rst b/Documentation/internals/contributing/coding-style-windows.rst\ndeleted file mode 100644\nindex d0868f7b3..000000000\n--- a/Documentation/internals/contributing/coding-style-windows.rst\n+++ /dev/null\n@@ -1,183 +0,0 @@\n-..\n- Licensed under the Apache License, Version 2.0 (the \"License\"); you may\n- not use this file except in compliance with the License. You may obtain\n- a copy of the License at\n-\n- http://www.apache.org/licenses/LICENSE-2.0\n-\n- Unless required by applicable law or agreed to in writing, software\n- distributed under the License is distributed on an \"AS IS\" BASIS, WITHOUT\n- WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the\n- License for the specific language governing permissions and limitations\n- under the License.\n-\n- Convention for heading levels in Open vSwitch documentation:\n-\n- ======= Heading 0 (reserved for the title in a document)\n- ------- Heading 1\n- ~~~~~~~ Heading 2\n- +++++++ Heading 3\n- ''''''' Heading 4\n-\n- Avoid deeper levels because they do not render well.\n-\n-=============================\n-Windows Datapath Coding Style\n-=============================\n-\n-The :doc:`coding style ` guide gives the flexibility for each\n-platform to use its own coding style for the kernel datapath. This file\n-describes the specific coding style used in most of the C files in the Windows\n-kernel datapath of the Open vSwitch distribution.\n-\n-Most of the coding conventions applicable for the Open vSwitch distribution are\n-applicable to the Windows kernel datapath as well. There are some exceptions\n-and new guidelines owing to the commonly followed practices in Windows\n-kernel/driver code. They are noted as follows:\n-\n-Basics\n-------\n-\n-- Limit lines to 79 characters.\n-\n- Many times, this is not possible due to long names of functions and it is\n- fine to go beyond the characters limit. One common example is when calling\n- into NDIS functions.\n-\n-Types\n------\n-\n-Use data types defined by Windows for most of the code. This is a common\n-practice in Windows driver code, and it makes integrating with the data\n-structures and functions defined by Windows easier. Example: ``DWORD`` and\n-``BOOLEAN``.\n-\n-Use caution in portions of the code that interface with the OVS userspace. OVS\n-userspace does not use Windows specific data types, and when copying data back\n-and forth between kernel and userspace, care should be exercised.\n-\n-Naming\n-------\n-\n-It is common practice to use camel casing for naming variables, functions and\n-files in Windows. For types, especially structures, unions and enums, using\n-all upper case letters with words separated by '_' is common. These practices\n-can be used for OVS Windows datapath. However, use the following guidelines:\n-\n-- Use lower case to begin the name of a variable.\n-\n-- Do not use '_' to begin the name of the variable. '_' is to be used to begin\n- the parameters of a pre-processor macro.\n-\n-- Use upper case to begin the name of a function, enum, file name etc.\n-\n-- Static functions whose scope is limited to the file they are defined in can\n- be prefixed with '_'. This is not mandatory though.\n-\n-- For types, use all upper case for all letters with words separated by '_'. If\n- camel casing is preferred, use upper case for the first letter.\n-\n-- It is a common practice to define a pointer type by prefixing the letter 'P'\n- to a data type. The same practice can be followed here as well.\n-\n-For example::\n-\n- static __inline BOOLEAN\n- OvsDetectTunnelRxPkt(POVS_FORWARDING_CONTEXT ovsFwdCtx,\n- POVS_FLOW_KEY flowKey)\n- {\n- POVS_VPORT_ENTRY tunnelVport = NULL;\n-\n- if (!flowKey->ipKey.nwFrag &&\n- flowKey->ipKey.nwProto == IPPROTO_UDP &&\n- flowKey->ipKey.l4.tpDst == VXLAN_UDP_PORT_NBO) {\n- tunnelVport = OvsGetTunnelVport(OVSWIN_VPORT_TYPE_VXLAN);\n- ovsActionStats.rxVxlan++;\n- } else {\n- return FALSE;\n- }\n-\n- if (tunnelVport) {\n- ASSERT(ovsFwdCtx->tunnelRxNic == NULL);\n- ovsFwdCtx->tunnelRxNic = tunnelVport;\n- return TRUE;\n- }\n-\n- return FALSE;\n- }\n-\n-For declaring variables of pointer type, use of the pointer data type prefixed\n-with 'P' is preferred over using '*'. This is not mandatory though, and is only\n-prescribed since it is a common practice in Windows.\n-\n-Example, #1 is preferred over #2 though #2 is also equally correct:\n-\n-1. ``PNET_BUFFER_LIST curNbl;``\n-2. ``NET_BUFFER_LIST *curNbl;``\n-\n-Comments\n---------\n-\n-Comments should be written as full sentences that start with a capital letter\n-and end with a period. Putting two spaces between sentences is not necessary.\n-\n-``//`` can be used for comments as long as the comment is a single line\n-comment. For block comments, use ``/* */`` comments\n-\n-Functions\n----------\n-\n-Put the return type, function name, and the braces that surround the function's\n-code on separate lines, all starting in column 0.\n-\n-Before each function definition, write a comment that describes the function's\n-purpose, including each parameter, the return value, and side effects.\n-References to argument names should be given in single-quotes, e.g. 'arg'. The\n-comment should not include the function name, nor need it follow any formal\n-structure. The comment does not need to describe how a function does its work,\n-unless this information is needed to use the function correctly (this is often\n-better done with comments *inside* the function).\n-\n-Mention any side effects that the function has that are not obvious based on\n-the name of the function or based on the workflow it is called from.\n-\n-In the interest of keeping comments describing functions similar in structure,\n-use the following template.\n-\n-::\n-\n- /*\n- *----------------------------------------------------------------------------\n- * Any description of the function, arguments, return types, assumptions and\n- * side effects.\n- *----------------------------------------------------------------------------\n- */\n-\n-Source Files\n-------------\n-\n-Each source file should state its license in a comment at the very top,\n-followed by a comment explaining the purpose of the code that is in that file.\n-The comment should explain how the code in the file relates to code in other\n-files. The goal is to allow a programmer to quickly figure out where a given\n-module fits into the larger system.\n-\n-The first non-comment line in a .c source file should be::\n-\n- #include \n-\n-``#include`` directives should appear in the following order:\n-\n-1. ``#include ``\n-\n-2. The module's own headers, if any. Including this before any other header\n- (besides ````) ensures that the module's header file is\n- self-contained (see *Header Files*) below.\n-\n-3. Standard C library headers and other system headers, preferably in\n- alphabetical order. (Occasionally one encounters a set of system headers\n- that must be included in a particular order, in which case that order must\n- take precedence.)\n-\n-4. Open vSwitch headers, in alphabetical order. Use ``\"\"``, not ``<>``, to\n- specify Open vSwitch header names.\ndiff --git a/Documentation/internals/contributing/coding-style.rst b/Documentation/internals/contributing/coding-style.rst\nindex eef984e87..034fd4cef 100644\n--- a/Documentation/internals/contributing/coding-style.rst\n+++ b/Documentation/internals/contributing/coding-style.rst\n@@ -27,8 +27,7 @@ Coding Style\n \n This file describes the coding style used in most C files in the Open vSwitch\n distribution. However, Linux kernel code datapath directory follows the Linux\n-kernel's established coding conventions. For the Windows kernel datapath code,\n-use the coding style described in :doc:`coding-style-windows`.\n+kernel's established coding conventions.\n \n The following GNU indent options approximate this style.\n \ndiff --git a/Documentation/internals/contributing/index.rst b/Documentation/internals/contributing/index.rst\nindex 91304e60b..f60609650 100644\n--- a/Documentation/internals/contributing/index.rst\n+++ b/Documentation/internals/contributing/index.rst\n@@ -33,7 +33,6 @@ The below guides provide information on contributing to Open vSwitch itself.\n submitting-patches\n backporting-patches\n coding-style\n- coding-style-windows\n documentation-style\n inclusive-language\n libopenvswitch-abi\ndiff --git a/Documentation/intro/install/general.rst b/Documentation/intro/install/general.rst\nindex 8d46c2a75..b41a25225 100644\n--- a/Documentation/intro/install/general.rst\n+++ b/Documentation/intro/install/general.rst\n@@ -73,9 +73,6 @@ need the following software:\n \n - Clang 3.4 or later.\n \n- - MSVC 2013. Refer to :doc:`windows` for additional Windows build\n- instructions.\n-\n While OVS may be compatible with other compilers, optimal support for atomic\n operations may be missing, making OVS very slow (see ``lib/ovs-atomic.h``).\n \ndiff --git a/Documentation/intro/install/index.rst b/Documentation/intro/install/index.rst\nindex 885a65d6e..d5af6b470 100644\n--- a/Documentation/intro/install/index.rst\n+++ b/Documentation/intro/install/index.rst\n@@ -41,7 +41,6 @@ Installation from Source\n \n general\n netbsd\n- windows\n userspace\n dpdk\n afxdp\ndiff --git a/Documentation/intro/install/windows.rst b/Documentation/intro/install/windows.rst\ndeleted file mode 100644\nindex 165d807bf..000000000\n--- a/Documentation/intro/install/windows.rst\n+++ /dev/null\n@@ -1,1080 +0,0 @@\n-..\n- Licensed under the Apache License, Version 2.0 (the \"License\"); you may\n- not use this file except in compliance with the License. You may obtain\n- a copy of the License at\n-\n- http://www.apache.org/licenses/LICENSE-2.0\n-\n- Unless required by applicable law or agreed to in writing, software\n- distributed under the License is distributed on an \"AS IS\" BASIS, WITHOUT\n- WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the\n- License for the specific language governing permissions and limitations\n- under the License.\n-\n- Convention for heading levels in Open vSwitch documentation:\n-\n- ======= Heading 0 (reserved for the title in a document)\n- ------- Heading 1\n- ~~~~~~~ Heading 2\n- +++++++ Heading 3\n- ''''''' Heading 4\n-\n- Avoid deeper levels because they do not render well.\n-\n-=======================\n-Open vSwitch on Windows\n-=======================\n-\n-.. _windows-build-reqs:\n-\n-Build Requirements\n-------------------\n-\n-Open vSwitch on Linux uses autoconf and automake for generating Makefiles. It\n-will be useful to maintain the same build system while compiling on Windows\n-too. One approach is to compile Open vSwitch in a MinGW environment that\n-contains autoconf and automake utilities and then use Visual C++ as a compiler\n-and linker.\n-\n-The following explains the steps in some detail.\n-\n-- Mingw\n-\n- Install Mingw on a Windows machine by following the instructions on\n- `mingw.org `__.\n-\n- This should install mingw at ``C:\\Mingw`` and msys at ``C:\\Mingw\\msys``. Add\n- ``C:\\MinGW\\bin`` and ``C:\\Mingw\\msys\\1.0\\bin`` to PATH environment variable\n- of Windows.\n-\n- You can either use the MinGW installer or the command line utility\n- ``mingw-get`` to install both the base packages and additional packages like\n- automake and autoconf(version 2.68).\n-\n- Also make sure that ``/mingw`` mount point exists. If its not, please\n- add/create the following entry in ``/etc/fstab``::\n-\n- 'C:/MinGW /mingw'.\n-\n-- Python 3.7 or later.\n-\n- Install the latest Python 3.x from python.org and verify that its path is\n- part of Windows' PATH environment variable.\n- We require that you have pypiwin32 library installed.\n- The library can be installed via pip command:\n-\n- ::\n-\n- $ pip install pypiwin32\n-\n-- Visual Studio\n-\n- You will need at least Visual Studio 2013 (update 4) to compile userspace\n- binaries. In addition to that, if you want to compile the kernel module you\n- will also need to install Windows Driver Kit (WDK) 8.1 Update or later.\n- To be able to build the kernel module you need\n- `WiX Toolset `__ .\n-\n- We recommend using the latest Visual Studio version together with the latest\n- WDK installed.\n-\n- It is important to get the Visual Studio related environment variables and to\n- have the $PATH inside the bash to point to the proper compiler and linker.\n- One easy way to achieve this for VS2013 is to get into the \"VS2013 x86 Native\n- Tools Command Prompt\" (in a default installation of Visual Studio 2013 this\n- can be found under the following location: ``C:\\Program Files (x86)\\Microsoft\n- Visual Studio 12.0\\Common7\\Tools\\Shortcuts``) and through it enter into the\n- bash shell available from msys by typing ``bash --login``.\n-\n- There is support for generating 64 bit binaries too. To compile under x64,\n- open the \"VS2013 x64 Native Tools Command Prompt\" (if your current running OS\n- is 64 bit) or \"VS2013 x64 Cross Tools Command Prompt\" (if your current\n- running OS is not 64 bit) instead of opening its x86 variant. This will\n- point the compiler and the linker to their 64 bit equivalent.\n-\n- If after the above step, a ``which link`` inside MSYS's bash says,\n- ``/bin/link.exe``, rename ``/bin/link.exe`` to something else so that the\n- Visual studio's linker is used. You should also see a 'which sort' report\n- ``/bin/sort.exe``.\n-\n-- PThreads4W\n-\n- For pthread support, install the library, dll and includes of PThreads4W\n- project from `sourceware\n- `__ to a directory\n- (e.g.: ``C:/pthread``). You should add the PThreads4W's dll path\n- (e.g.: ``C:\\pthread\\bin``) to the Windows' PATH environment variable.\n-\n-- OpenSSL\n-\n- To get SSL support for Open vSwitch on Windows, you will need to install\n- `OpenSSL for Windows `__\n-\n- Note down the directory where OpenSSL is installed (e.g.:\n- ``C:/OpenSSL-Win64``) for later use.\n-\n-.. note::\n-\n- Commands prefixed by ``$`` must be run in the Bash shell provided by MinGW.\n- Open vSwitch commands, such as ``ovs-dpctl`` are shown running under the DOS\n- shell (``cmd.exe``), as indicated by the ``>`` prefix, but will also run\n- under Bash. The remainder, prefixed by ``>``, are PowerShell commands and\n- must be run in PowerShell.\n-\n-Install Requirements\n---------------------\n-\n-* Share network adaptors\n-\n- We require that you don't disable the \"Allow management operating system to\n- share this network adapter\" under 'Virtual Switch Properties' > 'Connection\n- type: External network', in the Hyper-V virtual network switch configuration.\n-\n-* Checksum Offloads\n-\n- While there is some support for checksum/segmentation offloads in software,\n- this is still a work in progress. Till the support is complete we recommend\n- disabling TX/RX offloads for both the VM's as well as the Hyper-V.\n-\n-Bootstrapping\n--------------\n-\n-This step is not needed if you have downloaded a released tarball. If\n-you pulled the sources directly from an Open vSwitch Git tree or got a\n-Git tree snapshot, then run boot.sh in the top source directory to build\n-the \"configure\" script:\n-\n-::\n-\n- $ ./boot.sh\n-\n-.. _windows-configuring:\n-\n-Configuring\n------------\n-\n-Configure the package by running the configure script. You should provide some\n-configure options to choose the right compiler, linker, libraries, Open vSwitch\n-component installation directories, etc. For example:\n-\n-::\n-\n- $ ./configure CC=./build-aux/cccl LD=\"$(which link)\" \\\n- LIBS=\"-lws2_32 -lShlwapi -liphlpapi -lwbemuuid -lole32 -loleaut32\" \\\n- --prefix=\"C:/openvswitch/usr\" \\\n- --localstatedir=\"C:/openvswitch/var\" \\\n- --sysconfdir=\"C:/openvswitch/etc\" \\\n- --with-pthread=\"C:/pthread\"\n-\n-.. note::\n-\n- By default, the above enables compiler optimization for fast code. For\n- default compiler optimization, pass the ``--with-debug`` configure option.\n-\n-To configure with SSL support, add the requisite additional options:\n-\n-::\n-\n- $ ./configure CC=./build-aux/cccl LD=\"`which link`\" \\\n- LIBS=\"-lws2_32 -lShlwapi -liphlpapi -lwbemuuid -lole32 -loleaut32\" \\\n- --prefix=\"C:/openvswitch/usr\" \\\n- --localstatedir=\"C:/openvswitch/var\"\n- --sysconfdir=\"C:/openvswitch/etc\" \\\n- --with-pthread=\"C:/pthread\" \\\n- --enable-ssl --with-openssl=\"C:/OpenSSL-Win64\"\n-\n-Finally, to the kernel module also:\n-\n-::\n-\n- $ ./configure CC=./build-aux/cccl LD=\"`which link`\" \\\n- LIBS=\"-lws2_32 -lShlwapi -liphlpapi -lwbemuuid -lole32 -loleaut32\" \\\n- --prefix=\"C:/openvswitch/usr\" \\\n- --localstatedir=\"C:/openvswitch/var\" \\\n- --sysconfdir=\"C:/openvswitch/etc\" \\\n- --with-pthread=\"C:/pthread\" \\\n- --enable-ssl --with-openssl=\"C:/OpenSSL-Win64\" \\\n- --with-vstudiotarget=\"\" \\\n- --with-vstudiotargetver=\"\"\n-\n-Possible values for ```` are: ``Debug`` and ``Release``\n-Possible values for ```` is a comma separated list\n-of target versions to compile among: ``Win8,Win8.1,Win10``\n-\n-.. note::\n-\n- You can directly use the Visual Studio 2013 IDE to compile the kernel\n- datapath. Open the ovsext.sln file in the IDE and build the solution.\n-\n-Refer to :doc:`general` for information on additional configuration options.\n-\n-.. _windows-building:\n-\n-Building\n---------\n-\n-Once correctly configured, building Open vSwitch on Windows is similar to\n-building on Linux, FreeBSD, or NetBSD.\n-\n-#. Run make for the ported executables in the top source directory, e.g.:\n-\n- ::\n-\n- $ make\n-\n- For faster compilation, you can pass the ``-j`` argument to make. For\n- example, to run 4 jobs simultaneously, run ``make -j4``.\n-\n- .. note::\n-\n- MSYS 1.0.18 has a bug that causes parallel make to hang. You can overcome\n- this by downgrading to MSYS 1.0.17. A simple way to downgrade is to exit\n- all MinGW sessions and then run the below command from MSVC developers\n- command prompt.:\n-\n- ::\n-\n- > mingw-get upgrade msys-core-bin=1.0.17-1\n-\n-#. To run all the unit tests in Open vSwitch, one at a time:\n-\n- ::\n-\n- $ make check\n-\n- To run all the unit tests in Open vSwitch, up to 8 in parallel:\n-\n- ::\n-\n- $ make check TESTSUITEFLAGS=\"-j8\"\n-\n-#. To install all the compiled executables on the local machine, run:\n-\n- ::\n-\n- $ make install\n-\n- .. note::\n-\n- This will install the Open vSwitch executables in ``C:/openvswitch``. You\n- can add ``C:\\openvswitch\\usr\\bin`` and ``C:\\openvswitch\\usr\\sbin`` to\n- Windows' PATH environment variable for easy access.\n-\n-The Kernel Module\n-~~~~~~~~~~~~~~~~~\n-\n-If you are building the kernel module, you will need to copy the below files to\n-the target Hyper-V machine.\n-\n-- ``./datapath-windows/x64/Win8.1Debug/package/ovsext.inf``\n-- ``./datapath-windows/x64/Win8.1Debug/package/OVSExt.sys``\n-- ``./datapath-windows/x64/Win8.1Debug/package/ovsext.cat``\n-- ``./datapath-windows/misc/install.cmd``\n-- ``./datapath-windows/misc/uninstall.cmd``\n-\n-.. note::\n-\n- The above path assumes that the kernel module has been built using Windows\n- DDK 8.1 in Debug mode. Change the path appropriately, if a different WDK has\n- been used.\n-\n-Now run ``./uninstall.cmd`` to remove the old extension. Once complete, run\n-``./install.cmd`` to insert the new one. For this to work you will have to\n-turn on ``TESTSIGNING`` boot option or 'Disable Driver Signature\n-Enforcement' during boot. The following commands can be used:\n-\n-::\n-\n- > bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS\n- > bcdedit /set TESTSIGNING ON\n- > bcdedit /set nointegritychecks ON\n-\n-.. note::\n-\n- You may have to restart the machine for the settings to take effect.\n-\n-In the Virtual Switch Manager configuration you can enable the Open vSwitch\n-Extension on an existing switch or create a new switch. If you are using an\n-existing switch, make sure to enable the \"Allow Management OS\" option for VXLAN\n-to work (covered later).\n-\n-The command to create a new switch named 'OVS-Extended-Switch' using a physical\n-NIC named 'Ethernet 1' is:\n-\n-::\n-\n- PS > New-VMSwitch \"OVS-Extended-Switch\" -NetAdapterName \"Ethernet 1\"\n-\n-.. note::\n-\n- You can obtain the list of physical NICs on the host using 'Get-NetAdapter'\n- command.\n-\n-In the properties of any switch, you should now see \"Open vSwitch Extension\"\n-under 'Extensions'. Click the check box to enable the extension.\n-An alternative way to do the same is to run the following command:\n-\n-::\n-\n- PS > Enable-VMSwitchExtension \"Open vSwitch Extension\" OVS-Extended-Switch\n-\n-.. note::\n-\n- If you enabled the extension using the command line, a delay of a few\n- seconds has been observed for the change to be reflected in the UI. This is\n- not a bug in Open vSwitch.\n-\n-Starting\n---------\n-\n-.. important::\n-\n- The following steps assume that you have installed the Open vSwitch\n- utilities in the local machine via 'make install'.\n-\n-Before starting ovs-vswitchd itself, you need to start its configuration\n-database, ovsdb-server. Each machine on which Open vSwitch is installed should\n-run its own copy of ovsdb-server. Before ovsdb-server itself can be started,\n-configure a database that it can use:\n-\n-::\n-\n- > ovsdb-tool create C:\\openvswitch\\etc\\openvswitch\\conf.db \\\n- C:\\openvswitch\\usr\\share\\openvswitch\\vswitch.ovsschema\n-\n-Configure ovsdb-server to use database created above and to listen on a Unix\n-domain socket:\n-\n-::\n-\n- > ovsdb-server -vfile:info --remote=punix:db.sock --log-file \\\n- --pidfile --detach\n-\n-.. note::\n-\n- The logfile is created at ``C:/openvswitch/var/log/openvswitch/``\n-\n-Initialize the database using ovs-vsctl. This is only necessary the first time\n-after you create the database with ovsdb-tool, though running it at any time is\n-harmless:\n-\n-::\n-\n- > ovs-vsctl --no-wait init\n-\n-.. tip::\n-\n- If you would later like to terminate the started ovsdb-server, run:\n-\n- ::\n-\n- > ovs-appctl -t ovsdb-server exit\n-\n-Start the main Open vSwitch daemon, telling it to connect to the same Unix\n-domain socket:\n-\n-::\n-\n- > ovs-vswitchd -vfile:info --log-file --pidfile --detach\n-\n-.. tip::\n-\n- If you would like to terminate the started ovs-vswitchd, run:\n-\n- ::\n-\n- > ovs-appctl exit\n-\n-.. note::\n-\n- The logfile is created at ``C:/openvswitch/var/log/openvswitch/``\n-\n-Validating\n-----------\n-\n-At this point you can use ovs-vsctl to set up bridges and other Open vSwitch\n-features.\n-\n-Add bridges\n-~~~~~~~~~~~\n-\n-Let's start by creating an integration bridge, ``br-int`` and a PIF bridge,\n-``br-pif``:\n-\n-::\n-\n- > ovs-vsctl add-br br-int\n- > ovs-vsctl add-br br-pif\n-\n-.. note::\n-\n- There's a known bug that running the ovs-vsctl command does not terminate.\n- This is generally solved by having ovs-vswitchd running. If you face the\n- issue despite that, hit Ctrl-C to terminate ovs-vsctl and check the output\n- to see if your command succeeded.\n-\n-Validate that ports are added by dumping from both ovs-dpctl and ovs-vsctl:\n-\n-::\n-\n- > ovs-dpctl show\n- system@ovs-system:\n- lookups: hit:0 missed:0 lost:0\n- flows: 0\n- port 2: br-pif (internal) <<< internal port on 'br-pif' bridge\n- port 1: br-int (internal) <<< internal port on 'br-int' bridge\n-\n- > ovs-vsctl show\n- a56ec7b5-5b1f-49ec-a795-79f6eb63228b\n- Bridge br-pif\n- Port br-pif\n- Interface br-pif\n- type: internal\n- Bridge br-int\n- Port br-int\n- Interface br-int\n- type: internal\n-\n-.. note::\n-\n- There's a known bug that the ports added to OVSDB via ovs-vsctl don't get to\n- the kernel datapath immediately, ie. they don't show up in the output of\n- ``ovs-dpctl show`` even though they show up in output of ``ovs-vsctl show``.\n- In order to workaround this issue, restart ovs-vswitchd. (You can terminate\n- ovs-vswitchd by running ``ovs-appctl exit``.)\n-\n-Add physicals NICs (PIF)\n-~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-Now, let's add the physical NIC and the internal port to ``br-pif``. In OVS for\n-Hyper-V, we use the name of the adapter on top of which the Hyper-V virtual\n-switch was created, as a special name to refer to the physical NICs connected\n-to the Hyper-V switch, e.g. if we created the Hyper-V virtual switch on top of\n-the adapter named ``Ethernet0``, then in OVS we use that name (``Ethernet0``)\n-as a special name to refer to that adapter.\n-\n-.. note::\n-\n- We assume that the OVS extension is enabled Hyper-V switch.\n-\n-Internal ports are the virtual adapters created on the Hyper-V switch using the\n-``ovs-vsctl add-br `` command. By default they are created under the\n-following rule \"\" and the adapters are disabled. One needs to\n-enable them and set the corresponding values to it to make them IP-able.\n-\n-As a whole example, if we issue the following in a powershell console:\n-\n-::\n-\n- PS > Get-NetAdapter | select Name,InterfaceDescription\n- Name InterfaceDescription\n- ---- --------------------\n- Ethernet1 Intel(R) PRO/1000 MT Network Connection\n- br-pif Hyper-V Virtual Ethernet Adapter #2\n- Ethernet0 Intel(R) PRO/1000 MT Network Connection #2\n- br-int Hyper-V Virtual Ethernet Adapter #3\n-\n- PS > Get-VMSwitch\n- Name SwitchType NetAdapterInterfaceDescription\n- ---- ---------- ------------------------------\n- external External Intel(R) PRO/1000 MT Network Connection #2\n-\n-We can see that we have a switch(external) created upon adapter name\n-'Ethernet0' with the internal ports under name 'br-pif' and 'br-int'. Thus\n-resulting into the following ovs-vsctl commands:\n-\n-::\n-\n- > ovs-vsctl add-port br-pif Ethernet0\n-\n-Dumping the ports should show the additional ports that were just added:\n-\n-::\n-\n- > ovs-dpctl show\n- system@ovs-system:\n- lookups: hit:0 missed:0 lost:0\n- flows: 0\n- port 2: br-pif (internal) <<< internal port\n- adapter on\n- Hyper-V switch\n- port 1: br-int (internal) <<< internal port\n- adapter on\n- Hyper-V switch\n- port 3: Ethernet0 <<< Physical NIC\n-\n- > ovs-vsctl show\n- a56ec7b5-5b1f-49ec-a795-79f6eb63228b\n- Bridge br-pif\n- Port br-pif\n- Interface br-pif\n- type: internal\n- Port \"Ethernet0\"\n- Interface \"Ethernet0\"\n- Bridge br-int\n- Port br-int\n- Interface br-int\n- type: internal\n-\n-Add virtual interfaces (VIFs)\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-Adding VIFs to Open vSwitch is a two step procedure. The first step is to\n-assign a 'OVS port name' which is a unique name across all VIFs on this\n-Hyper-V. The next step is to add the VIF to the ovsdb using its 'OVS port\n-name' as key.\n-\n-First, assign a unique 'OVS port name' to the VIF. The VIF needs to have been\n-disconnected from the Hyper-V switch before assigning a 'OVS port name' to it.\n-In the example below, we assign a 'OVS port name' called ``ovs-port-a`` to a\n-VIF on a VM ``VM1``. By using index 0 for ``$vnic``, the first VIF of the VM\n-is being addressed. After assigning the name ``ovs-port-a``, the VIF is\n-connected back to the Hyper-V switch with name ``OVS-HV-Switch``, which is\n-assumed to be the Hyper-V switch with OVS extension enabled.:\n-\n-::\n-\n- PS > import-module .\\datapath-windows\\misc\\OVS.psm1\n- PS > $vnic = Get-VMNetworkAdapter \n- PS > Disconnect-VMNetworkAdapter -VMNetworkAdapter $vnic[0]\n- PS > $vnic[0] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-a\n- PS > Connect-VMNetworkAdapter -VMNetworkAdapter $vnic[0] \\\n- -SwitchName OVS-Extended-Switch\n-\n-Next, add the VIFs to ``br-int``:\n-\n-::\n-\n- > ovs-vsctl add-port br-int ovs-port-a\n-\n-Dumping the ports should show the additional ports that were just added:\n-\n-::\n-\n- > ovs-dpctl show\n- system@ovs-system:\n- lookups: hit:0 missed:0 lost:0\n- flows: 0\n- port 4: ovs-port-a\n- port 2: br-pif (internal)\n- port 1: br-int (internal\n- port 3: Ethernet0\n-\n- > ovs-vsctl show\n- 4cd86499-74df-48bd-a64d-8d115b12a9f2\n- Bridge br-pif\n- Port \"vEthernet (external)\"\n- Interface \"vEthernet (external)\"\n- Port \"Ethernet0\"\n- Interface \"Ethernet0\"\n- Port br-pif\n- Interface br-pif\n- type: internal\n- Bridge br-int\n- Port br-int\n- Interface br-int\n- type: internal\n- Port \"ovs-port-a\"\n- Interface \"ovs-port-a\"\n-\n-Add multiple NICs to be managed by OVS\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-To leverage support of multiple NICs into OVS, we will be using the MSFT\n-cmdlets for forwarding team extension. More documentation about them can be\n-found at technet_.\n-\n-.. _technet: https://technet.microsoft.com/en-us/library/jj553812%28v=wps.630%29.aspx\n-\n-For example, to set up a switch team combined from ``Ethernet0 2`` and\n-``Ethernet1 2`` named ``external``:\n-\n-::\n-\n- PS > Get-NetAdapter\n- Name InterfaceDescription\n- ---- --------------------\n- br-int Hyper-V Virtual Ethernet Adapter #3\n- br-pif Hyper-V Virtual Ethernet Adapter #2\n- Ethernet3 2 Intel(R) 82574L Gigabit Network Co...#3\n- Ethernet2 2 Intel(R) 82574L Gigabit Network Co...#4\n- Ethernet1 2 Intel(R) 82574L Gigabit Network Co...#2\n- Ethernet0 2 Intel(R) 82574L Gigabit Network Conn...\n-\n- PS > New-NetSwitchTeam -Name external -TeamMembers \"Ethernet0 2\",\"Ethernet1 2\"\n-\n- PS > Get-NetSwitchTeam\n- Name : external\n- Members : {Ethernet1 2, Ethernet0 2}\n-\n-This will result in a new adapter bound to the host called ``external``:\n-\n-::\n-\n- PS > Get-NetAdapter\n- Name InterfaceDescription\n- ---- --------------------\n- br-test Hyper-V Virtual Ethernet Adapter #4\n- br-pif Hyper-V Virtual Ethernet Adapter #2\n- external Microsoft Network Adapter Multiplexo...\n- Ethernet3 2 Intel(R) 82574L Gigabit Network Co...#3\n- Ethernet2 2 Intel(R) 82574L Gigabit Network Co...#4\n- Ethernet1 2 Intel(R) 82574L Gigabit Network Co...#2\n- Ethernet0 2 Intel(R) 82574L Gigabit Network Conn...\n-\n-Next we will set up the Hyper-V VMSwitch on the new adapter ``external``:\n-\n-::\n-\n- PS > New-VMSwitch -Name external -NetAdapterName external \\\n- -AllowManagementOS $false\n-\n-Under OVS the adapters under the team ``external``, ``Ethernet0 2`` and\n-``Ethernet1 2``, can be added either under a bond device or separately.\n-\n-The following example shows how the bridges look with the NICs being\n-separated:\n-\n-::\n-\n- > ovs-vsctl show\n- 6cd9481b-c249-4ee3-8692-97b399dd29d8\n- Bridge br-test\n- Port br-test\n- Interface br-test\n- type: internal\n- Port \"Ethernet1 2\"\n- Interface \"Ethernet1 2\"\n- Bridge br-pif\n- Port \"Ethernet0 2\"\n- Interface \"Ethernet0 2\"\n- Port br-pif\n- Interface br-pif\n- type: internal\n-\n-Add patch ports and configure VLAN tagging\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-The Windows Open vSwitch implementation support VLAN tagging in the switch.\n-Switch VLAN tagging along with patch ports between ``br-int`` and ``br-pif`` is\n-used to configure VLAN tagging functionality between two VMs on different\n-Hyper-Vs. To start, add a patch port from ``br-int`` to ``br-pif``:\n-\n-::\n-\n- > ovs-vsctl add-port br-int patch-to-pif\n- > ovs-vsctl set interface patch-to-pif type=patch \\\n- options:peer=patch-to-int\n-\n-Add a patch port from ``br-pif`` to ``br-int``:\n-\n-::\n-\n- > ovs-vsctl add-port br-pif patch-to-int\n- > ovs-vsctl set interface patch-to-int type=patch \\\n- options:peer=patch-to-pif\n-\n-Re-Add the VIF ports with the VLAN tag:\n-\n-::\n-\n- > ovs-vsctl add-port br-int ovs-port-a tag=900\n- > ovs-vsctl add-port br-int ovs-port-b tag=900\n-\n-Add tunnels\n-~~~~~~~~~~~\n-\n-#. IPv4 tunnel, e.g.:\n-\n- The Windows Open vSwitch implementation supports VXLAN and Geneve tunnels.\n- To add tunnels. For example, first add the tunnel port between\n- 172.168.201.101 <->172.168.201.102:\n-\n- ::\n-\n- > ovs-vsctl add-port br-int tun-1\n- > ovs-vsctl set Interface tun-1 type=\n- > ovs-vsctl set Interface tun-1 options:local_ip=172.168.201.101\n- > ovs-vsctl set Interface tun-1 options:remote_ip=172.168.201.102\n- > ovs-vsctl set Interface tun-1 options:in_key=flow\n- > ovs-vsctl set Interface tun-1 options:out_key=flow\n-\n- ...and the tunnel port between 172.168.201.101 <-> 172.168.201.105:\n-\n- ::\n-\n- > ovs-vsctl add-port br-int tun-2\n- > ovs-vsctl set Interface tun-2 type=\n- > ovs-vsctl set Interface tun-2 options:local_ip=172.168.201.102\n- > ovs-vsctl set Interface tun-2 options:remote_ip=172.168.201.105\n- > ovs-vsctl set Interface tun-2 options:in_key=flow\n- > ovs-vsctl set Interface tun-2 options:out_key=flow\n-\n- Where ```` is one of: ``geneve`` or ``vxlan``\n-\n- .. note::\n-\n- Any patch ports created between br-int and br-pif MUST be deleted prior\n- to adding tunnels.\n-\n-#. IPv6 tunnel, e.g.:\n-\n- To add IPV6 Geneve tunnels. For example, add the tunnel port between\n- 5000::2 <-> 5000::9.\n-\n- ::\n-\n- > ovs-vsctl add-port br-int tun-3 -- set interface tun-3 type=Geneve \\\n- options:csum=true options:key=flow options:local_ip=\"5000::2\"\\\n- options:remote_ip=flow\n-\n- add the tunnel port between 5000::2 <-> 5000::9\n-\n- > ovs-ofctl add-flow br-int \"table=0,priority=100,ipv6,ipv6_src=6000::2 \\\n- actions=load:0x9->NXM_NX_TUN_IPV6_DST[0..63], \\\n- load:0x5000000000000000->NXM_NX_TUN_IPV6_DST[64..127], output:tun-3\"\n-\n- add the specified flow from 6000::2 go via IPV6 Geneve tunnel\n-\n- .. note::\n-\n- Till the checksum offload support is complete we recommend\n- disabling TX/RX offloads for IPV6 on Windows VM.\n-\n-Add conntrack for ipv6\n-~~~~~~~~~~~~~~~~~~~~~~\n-\n-The Windows Open vSwitch implementation support conntrack ipv6. To use the\n-conntrack ipv6. Using the following commands. Take tcp6(replace Protocol to\n-icmp6, udp6 to other protocol) for example.\n-\n-::\n-\n- normal scenario\n- Vif38(20::1, ofport:2)->Vif40(20:2, ofport:3)\n- Vif38Name=\"podvif38\"\n- Vif40Name=\"podvif40\"\n- Vif38Port=2\n- Vif38Address=\"20::1\"\n- Vif40Port=3\n- Vif40Address=\"20::2\"\n- Vif40MacAddressCli=\"00-15-5D-F0-01-0C\"\n- Vif38MacAddressCli=\"00-15-5D-F0-01-0b\"\n- Protocol=\"tcp6\"\n- > netsh int ipv6 set neighbors $Vif38Name $Vif40Address \\\n- Vif40MacAddressCli\n- > netsh int ipv6 set neighbors $Vif40Name $Vif38Address \\\n- $Vif38MacAddressCli\n- > ovs-ofctl del-flows --strict br-int \"table=0,priority=0\"\n- > ovs-ofctl add-flow br-int \"table=0,priority=1,ip6, \\\n- ipv6_dst=$Vif40Address,$Protocol,actions=ct(table=1)\"\n- > ovs-ofctl add-flow br-int \"table=0,priority=1,ip6, \\\n- ipv6_dst=$Vif38Address,$Protocol,actions=ct(table=1)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1,ip6,ct_state=+new+trk, \\\n- $Protocol,actions=ct(commit,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=2,ip6, \\\n- ct_state=-new+rpl+trk,$Protocol,actions=ct(commit,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1,ip6, \\\n- ct_state=+trk+est-new,$Protocol,actions=ct(commit,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=2,priority=1,ip6, \\\n- ipv6_dst=$Vif38Address,$Protocol,actions=output:$Vif38Port\"\n- > ovs-ofctl add-flow br-int \"table=2,priority=1,ip6, \\\n- ipv6_dst=$Vif40Address,$Protocol,actions=output:$Vif40Port\"\n-\n-\n-::\n-\n- nat scenario\n- Vif38(20::1, ofport:2) -> nat address(20::9) -> Vif42(21::3, ofport:4)\n- Due to not construct flow to return neighbor mac address,\n- we set the neighbor mac address manually.\n- Vif38Name=\"podvif38\"\n- Vif42Name=\"podvif42\"\n- Vif38Ip=\"20::1\"\n- Vif38Port=2\n- Vif42Port=4\n- NatAddress=\"20::9\"\n- NatMacAddress=\"aa:bb:cc:dd:ee:ff\"\n- NatMacAddressForCli=\"aa-bb-cc-dd-ee-ff\"\n- Vif42Ip=\"21::3\"\n- Vif38MacAddress=\"00:15:5D:F0:01:0B\"\n- Vif38MacAddressCli=\"00-15-5D-F0-01-0B\"\n- Vif42MacAddress=\"00:15:5D:F0:01:0D\"\n- Protocol=\"tcp6\"\n- > netsh int ipv6 set neighbors $Vif38Name $NatAddress \\\n- $NatMacAddressForCli\n- > netsh int ipv6 set neighbors $Vif42Name $Vif38Ip \\\n- $Vif38MacAddressCli\n- > ovs-ofctl del-flows --strict br-int \"table=0,priority=0\"\n- > ovs-ofctl add-flow br-int \"table=0, priority=2,ipv6, \\\n- dl_dst=$NatMacAddress,ct_state=-trk,$Protocol \\\n- actions=ct(table=1,zone=456,nat)\"\n- > ovs-ofctl add-flow br-int \"table=0, priority=1,ipv6,ct_state=-trk, \\\n- ip6,$Protocol actions=ct(nat, zone=456,table=1)\"\n- > ovs-ofctl add-flow br-int \"table=1, ipv6,in_port=$Vif38Port, \\\n- ipv6_dst=$NatAddress,$Protocol,ct_state=+trk+new, \\\n- actions=ct(commit,nat(dst=$Vif42Ip),zone=456, \\\n- exec(set_field:1->ct_mark)),mod_dl_src=$NatMacAddress, \\\n- mod_dl_dst=$Vif42MacAddress,output:$Vif42Port\"\n- > ovs-ofctl add-flow br-int \"table=1, ipv6,ct_state=+dnat,$Protocol, \\\n- action=resubmit(,2)\"\n- > ovs-ofctl add-flow br-int \"table=1, ipv6,ct_state=+trk+snat, \\\n- $Protocol, action=resubmit(,2)\"\n- > ovs-ofctl add-flow br-int \"table=2, ipv6,in_port=$Vif38Port, \\\n- ipv6_dst=$Vif42Ip,$Protocol, actions=mod_dl_src=$NatMacAddress, \\\n- mod_dl_dst=$Vif42MacAddress,output:$Vif42Port\"\n- > ovs-ofctl add-flow br-int \"table=2, ipv6,in_port=$Vif42Port, \\\n- ct_state=-new+est,ct_mark=1,ct_zone=456,$Protocol, \\\n- actions=mod_dl_src=$NatMacAddress,mod_dl_dst=$Vif38MacAddress, \\\n- output:$Vif38Port\"\n-\n-Ftp is a specific protocol, it contains an related flow, we need to match is\n-related state.\n-\n-::\n-\n- normal scenario\n- Vif38(20::1, ofport:2)->Vif40(20:2, ofport:3)\n- Vif38Name=\"podvif70\"\n- Vif40Name=\"Ethernet1\"\n- Vif38Port=2\n- Vif38Address=\"20::88\"\n- Vif40Port=3\n- Vif40Address=\"20::45\"\n- Vif40MacAddressCli=\"00-50-56-98-9d-97\"\n- Vif38MacAddressCli=\"00-15-5D-F0-01-0B\"\n- Protocol=\"tcp6\"\n- > netsh int ipv6 set neighbors $Vif38Name $Vif40Address $Vif40MacAddressCli\n- > netsh int ipv6 set neighbors $Vif42Name $Vif38Ip $Vif38MacAddressCli\n- > ovs-ofctl del-flows br-int --strict \"table=0,priority=0\"\n- > ovs-ofctl add-flow br-int \"table=0,priority=1,$Protocol\n- actions=ct(table=1)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1,tp_dst=21, $Protocol,\\\n- actions=ct(commit,table=2,alg=ftp)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1,tp_src=21, $Protocol,\\\n- actions=ct(commit,table=2,alg=ftp)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1, ct_state=+new+trk+rel,\\\n- $Protocol,actions=ct(commit,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1, \\\n- ct_state=-new+trk+est+rel,$Protocol,actions=ct(commit,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=2,priority=1,ip6,\\\n- ipv6_dst=$Vif38Address,$Protocol,actions=output:$Vif38Port\"\n- > ovs-ofctl add-flow br-int \"table=2,priority=1,ip6,\\\n- ipv6_dst=$Vif40Address,$Protocol,actions=output:$Vif40Port\"\n-\n-\n-::\n-\n- nat scenario\n- Vif38(20::1, ofport:2) -> nat address(20::9) -> Vif42(21::3, ofport:4)\n- Due to not construct flow to return neighbor mac address, we set the\n- neighbor mac address manually\n- Vif38Name=\"podvif70\"\n- Vif42Name=\"Ethernet1\"\n- Vif38Ip=\"20::88\"\n- Vif38Port=2\n- Vif42Port=3\n- NatAddress=\"20::9\"\n- NatMacAddress=\"aa:bb:cc:dd:ee:ff\"\n- NatMacAddressForCli=\"aa-bb-cc-dd-ee-ff\"\n- Vif42Ip=\"21::3\"\n- Vif38MacAddress=\"00:15:5D:F0:01:14\"\n- Vif38MacAddressCli=\"00-15-5D-F0-01-14\"\n- Vif42MacAddress=\"00:50:56:98:9d:97\"\n- Protocol=\"tcp6\"\n- netsh int ipv6 set neighbors $Vif38Name $NatAddress $NatMacAddressForCli\n- netsh int ipv6 set neighbors $Vif42Name $Vif38Ip $Vif38MacAddressCli\n- > ovs-ofctl del-flows br-int --strict \"table=0,priority=0\"\n- > ovs-ofctl add-flow br-int \"table=0,priority=2,ipv6,ipv6_dst=$NatAddress,\\\n- ct_state=-trk,$Protocol actions=ct(table=1,zone=456)\"\n- > ovs-ofctl add-flow br-int \"table=0,priority=1,ipv6,ipv6_dst=$Vif38Ip,\\\n- ct_state=-trk,ip6,$Protocol actions=ct(zone=456,table=1)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=2,ipv6,in_port=$Vif38Port,\\\n- ipv6_dst=$NatAddress,ct_state=+trk-rel,tp_dst=21,$Protocol \\\n- actions=ct(commit,alg=ftp,nat(dst=$Vif42Ip),zone=456, \\\n- exec(set_field:1->ct_mark)),mod_dl_src=$NatMacAddress,\\\n- mod_dl_dst=$Vif42MacAddress,output:$Vif42Port\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1,ipv6,ct_state=+trk-rel,\\\n- ipv6_dst=$Vif38Ip,$Protocol,action=ct(nat,alg=ftp,zone=456,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=1,ipv6,ct_state=+trk+rel,\\\n- ipv6_dst=$NatAddress,$Protocol,\\\n- action=ct(table=2,commit,nat(dst=$Vif42Ip),\\\n- zone=456, exec(set_field:1->ct_mark))\"\n- > ovs-ofctl add-flow br-int \"table=1,ipv6,ct_state=+trk+rel,$Protocol,\\\n- ipv6_dst=$Vif38Ip, action=ct(nat,zone=456,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=2,ipv6,ipv6_dst=$Vif42Ip,$Protocol,\\\n- actions=mod_dl_src=$NatMacAddress, mod_dl_dst=$Vif42MacAddress,\\\n- output:$Vif42Port\"\n- > ovs-ofctl add-flow br-int \"table=2,ipv6,ipv6_dst=$Vif38Ip,\\\n- ct_state=-new+est,ct_mark=1,ct_zone=456,$Protocol,\\\n- actions=mod_dl_src=$NatMacAddress,mod_dl_dst=$Vif38MacAddress,\\\n- output:$Vif38Port\"\n- > ovs-ofctl add-flow br-int \"table=2,ipv6,ipv6_dst=$Vif38Ip,\\\n- ct_state=+new,ct_mark=1,ct_zone=456,$Protocol,\\\n- actions=mod_dl_src=$NatMacAddress,\\\n- mod_dl_dst=$Vif38MacAddress, output:$Vif38Port\"\n-\n-Tftp same with ftp, it also contains a related connection, we could use\n-following follow test the tftp connection.\n-\n-::\n-\n- normal scenario\n- Vif38Name=\"podvif70\"\n- Vif40Name=\"Ethernet1\"\n- Vif38Port=2\n- Vif38Address=\"20::88\"\n- Vif40Port=3\n- Vif40Address=\"20::45\"\n- Vif40MacAddressCli=\"00-50-56-98-9d-97\"\n- Vif38MacAddressCli=\"00-15-5D-F0-01-14\"\n- Protocol=\"udp6\"\n- netsh int ipv6 set neighbors $Vif38Name $Vif40Address $Vif40MacAddressCli\n- netsh int ipv6 set neighbors $Vif40Name $Vif38Address $Vif38MacAddressCli\n- > ovs-ofctl del-flows br-int --strict \"table=0,priority=0\"\n- > ovs-ofctl add-flow br-int \"table=0,priority=1,$Protocol,\n- ipv6_src=$Vif38Address actions=ct(table=1)\"\n- > ovs-ofctl add-flow br-int \"table=0,priority=1,$Protocol,\n- ipv6_src=$Vif40Address actions=ct(table=1)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1,ct_state=+new+trk-est,\n- tp_dst=69,$Protocol,udp6 actions=ct(commit,alg=tftp,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1,ct_state=-new+trk+est-rel,\\\n- udp6 $Protocol,actions=ct(commit,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1,ct_state=-new+trk+est+rel,\\\n- $Protocol,actions=ct(commit,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=1,priority=1,ct_state=+new+trk+rel,\\\n- $Protocol,actions=ct(commit,table=2)\"\n- > ovs-ofctl add-flow br-int \"table=2,priority=1,ip6,\\\n- ipv6_dst=$Vif38Address,$Protocol,actions=output:$Vif38Port\"\n- > ovs-ofctl add-flow br-int \"table=2,priority=1,ip6,\\\n- ipv6_dst=$Vif40Address,$Protocol,actions=output:$Vif40Port\"\n-\n-::\n-\n- nat scenario\n- Vif38Name=\"podvif70\"\n- Vif42Name=\"Ethernet1\"\n- Vif38Ip=\"20::88\"\n- Vif38Port=2\n- Vif42Port=3\n- NatAddress=\"20::9\"\n- NatMacAddress=\"aa:bb:cc:dd:ee:ff\"\n- NatMacAddressForCli=\"aa-bb-cc-dd-ee-ff\"\n- Vif42Ip=\"21::3\"\n- Vif38MacAddress=\"00:15:5D:F0:01:14\"\n- Vif38MacAddressCli=\"00-15-5D-F0-01-14\"\n- Vif42MacAddress=\"00:50:56:98:9d:97\"\n- Protocol=\"ip6\"\n- netsh int ipv6 set neighbors $Vif38Name $NatAddress $NatMacAddressForCli\n- netsh int ipv6 set neighbors $Vif42Name $Vif38Ip $Vif38MacAddressCli\n- > ovs-ofctl del-flows br-int --strict \"table=0,priority=0\"\n- > ovs-ofctl add-flow br-int \"table=0,priority=2,ipv6,\\\n- dl_dst=$NatMacAddress,ct_state=-trk,$Protocol \\\n- actions=ct(table=1,zone=456)\"\n- > ovs-ofctl add-flow br-int \"table=0,priority=1,ipv6,ct_state=-trk,ip6,\\\n- $Protocol actions=ct(table=1,zone=456)\"\n- > ovs-ofctl add-flow br-int \"table=1,in_port=$Vif38Port,\\\n- ipv6_dst=$NatAddress,ct_state=+trk+new-rel,$Protocol,udp6\\\n- actions=ct(commit,alg=tftp,nat(dst=$Vif42Ip),zone=456,\\\n- exec(set_field:1->ct_mark)),mod_dl_src=$NatMacAddress,\\\n- mod_dl_dst=$Vif42MacAddress,output:$Vif42Port\"\n- > ovs-ofctl add-flow br-int \"table=1,ipv6,in_port=$Vif42Port,\\\n- ipv6_dst=$Vif38Ip,ct_state=+trk+rel-rpl,$Protocol\\\n- actions=ct(commit,nat(src=$NatAddress),zone=456,\\\n- exec(set_field:1->ct_mark)),mod_dl_src=$NatMacAddress,\\\n- mod_dl_dst=$Vif38MacAddress,output:$Vif38Port\"\n- > ovs-ofctl add-flow br-int \"table=1,ipv6,ct_state=+trk+rel+est+rpl,\\\n- $Protocol,action=ct(nat,table=2,zone=456)\"\n- > ovs-ofctl add-flow br-int \"table=2,ipv6,in_port=$Vif38Port,\\\n- ct_state=+rel+dnat,ipv6_dst=$Vif42Ip,$Protocol,\\\n- actions=mod_dl_src=$NatMacAddress,mod_dl_dst=$Vif42MacAddress,\\\n- output:$Vif42Port\"\n- > ovs-ofctl add-flow br-int \"table=2,ipv6,in_port=$Vif42Port,\\\n- ct_state=-new+est,$Protocol,actions=mod_dl_src=$NatMacAddress,\\\n- mod_dl_dst=$Vif38MacAddress,output:$Vif38Port\"\n-\n-\n-.. note::\n-\n- Till the checksum offload support is complete we recommend\n- disabling TX/RX offloads for IPV6 on Windows VM.\n-\n-Windows Services\n-----------------\n-\n-Open vSwitch daemons come with support to run as a Windows service. The\n-instructions here assume that you have installed the Open vSwitch utilities and\n-daemons via ``make install``.\n-\n-To start, create the database:\n-\n-::\n-\n- > ovsdb-tool create C:/openvswitch/etc/openvswitch/conf.db \\\n- \"C:/openvswitch/usr/share/openvswitch/vswitch.ovsschema\"\n-\n-Create the ovsdb-server service and start it:\n-\n-::\n-\n- > sc create ovsdb-server \\\n- binpath=\"C:/openvswitch/usr/sbin/ovsdb-server.exe \\\n- C:/openvswitch/etc/openvswitch/conf.db \\\n- -vfile:info --log-file --pidfile \\\n- --remote=punix:db.sock --service --service-monitor\"\n- > sc start ovsdb-server\n-\n-.. tip::\n-\n- One of the common issues with creating a Windows service is with mungled\n- paths. You can make sure that the correct path has been registered with the\n- Windows services manager by running:\n-\n- ::\n-\n- > sc qc ovsdb-server\n-\n-Check that the service is healthy by running:\n-\n-::\n-\n- > sc query ovsdb-server\n-\n-Initialize the database:\n-\n-::\n-\n- > ovs-vsctl --no-wait init\n-\n-Create the ovs-vswitchd service and start it:\n-\n-::\n-\n- > sc create ovs-vswitchd \\\n- binpath=\"C:/openvswitch/usr/sbin/ovs-vswitchd.exe \\\n- --pidfile -vfile:info --log-file --service --service-monitor\"\n- > sc start ovs-vswitchd\n-\n-Check that the service is healthy by running:\n-\n-::\n-\n- > sc query ovs-vswitchd\n-\n-To stop and delete the services, run:\n-\n-::\n-\n- > sc stop ovs-vswitchd\n- > sc stop ovsdb-server\n- > sc delete ovs-vswitchd\n- > sc delete ovsdb-server\n-\n-TODO\n-----\n-\n-* Investigate the working of sFlow on Windows and re-enable the unit tests.\n-\n-* Investigate and add the feature to provide QoS.\n-\n-* Sign the driver.\ndiff --git a/Documentation/topics/index.rst b/Documentation/topics/index.rst\nindex 9ddb145dd..4db5fdff1 100644\n--- a/Documentation/topics/index.rst\n+++ b/Documentation/topics/index.rst\n@@ -47,7 +47,6 @@ OVS\n ovsdb-relay\n ovsdb-replication\n dpdk/index\n- windows\n language-bindings\n record-replay\n testing\ndiff --git a/Documentation/topics/windows.rst b/Documentation/topics/windows.rst\ndeleted file mode 100644\nindex 1f1b513e4..000000000\n--- a/Documentation/topics/windows.rst\n+++ /dev/null\n@@ -1,509 +0,0 @@\n-..\n- Licensed under the Apache License, Version 2.0 (the \"License\"); you may\n- not use this file except in compliance with the License. You may obtain\n- a copy of the License at\n-\n- http://www.apache.org/licenses/LICENSE-2.0\n-\n- Unless required by applicable law or agreed to in writing, software\n- distributed under the License is distributed on an \"AS IS\" BASIS, WITHOUT\n- WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the\n- License for the specific language governing permissions and limitations\n- under the License.\n-\n- Convention for heading levels in Open vSwitch documentation:\n-\n- ======= Heading 0 (reserved for the title in a document)\n- ------- Heading 1\n- ~~~~~~~ Heading 2\n- +++++++ Heading 3\n- ''''''' Heading 4\n-\n- Avoid deeper levels because they do not render well.\n-\n-=====================\n-OVS-on-Hyper-V Design\n-=====================\n-\n-This document provides details of the effort to develop Open vSwitch on\n-Microsoft Hyper-V. This document should give enough information to understand\n-the overall design.\n-\n-.. note::\n- The userspace portion of the OVS has been ported to Hyper-V in a separate\n- effort, and committed to the openvswitch repo. This document will mostly\n- emphasize on the kernel driver, though we touch upon some of the aspects of\n- userspace as well.\n-\n-Background Info\n----------------\n-\n-Microsoft's hypervisor solution - Hyper-V [1]_ implements a virtual switch\n-that is extensible and provides opportunities for other vendors to implement\n-functional extensions [2]_. The extensions need to be implemented as NDIS\n-drivers that bind within the extensible switch driver stack provided. The\n-extensions can broadly provide the functionality of monitoring, modifying and\n-forwarding packets to destination ports on the Hyper-V extensible switch.\n-Correspondingly, the extensions can be categorized into the following types and\n-provide the functionality noted:\n-\n-* Capturing extensions: monitoring packets\n-\n-* Filtering extensions: monitoring, modifying packets\n-\n-* Forwarding extensions: monitoring, modifying, forwarding packets\n-\n-As can be expected, the kernel portion (datapath) of OVS on Hyper-V solution\n-will be implemented as a forwarding extension.\n-\n-In Hyper-V, the virtual machine is called the Child Partition. Each VIF or\n-physical NIC on the Hyper-V extensible switch is attached via a port. Each port\n-is both on the ingress path or the egress path of the switch. The ingress path\n-is used for packets being sent out of a port, and egress is used for packet\n-being received on a port. By design, NDIS provides a layered interface. In this\n-layered interface, higher level layers call into lower level layers, in the\n-ingress path. In the egress path, it is the other way round. In addition, there\n-is a object identifier (OID) interface for control operations Eg. addition of a\n-port. The workflow for the calls is similar in nature to the packets, where\n-higher level layers call into the lower level layers. A good representational\n-diagram of this architecture is in [3]_.\n-\n-Windows Filtering Platform (WFP) [4]_ is a platform implemented on Hyper-V that\n-provides APIs and services for filtering packets. WFP has been utilized to\n-filter on some of the packets that OVS is not equipped to handle directly. More\n-details in later sections.\n-\n-IP Helper [5]_ is a set of API available on Hyper-V to retrieve information\n-related to the network configuration information on the host machine. IP Helper\n-has been used to retrieve some of the configuration information that OVS needs.\n-\n-Design\n-------\n-\n-::\n-\n- Various blocks of the OVS Windows implementation\n-\n- +-------------------------------+\n- | |\n- | CHILD PARTITION |\n- | |\n- +------+ +--------------+ | +-----------+ +------------+ |\n- | | | | | | | | | |\n- | ovs- | | OVS- | | | Virtual | | Virtual | |\n- | *ctl | | USERSPACE | | | Machine #1| | Machine #2 | |\n- | | | DAEMON | | | | | | |\n- +------+-++---+---------+ | +--+------+-+ +----+------++ | +--------+\n- | dpif- | | netdev- | | |VIF #1| |VIF #2| | |Physical|\n- | netlink | | windows | | +------+ +------+ | | NIC |\n- +---------+ +---------+ | || /\\ | +--------+\n- User /\\ /\\ | || *#1* *#4* || | /\\\n- =========||=========||============+------||-------------------||--+ ||\n- Kernel || || \\/ || ||=====/\n- \\/ \\/ +-----+ +-----+ *#5*\n- +-------------------------------+ | | | |\n- | +----------------------+ | | | | |\n- | | OVS Pseudo Device | | | | | |\n- | +----------------------+ | | | | |\n- | | Netlink Impl. | | | | | |\n- | ----------------- | | I | | |\n- | +------------+ | | N | | E |\n- | | Flowtable | +------------+ | | G | | G |\n- | +------------+ | Packet | |*#2*| R | | R |\n- | +--------+ | Processing | |<=> | E | | E |\n- | | WFP | | | | | S | | S |\n- | | Driver | +------------+ | | S | | S |\n- | +--------+ | | | | |\n- | | | | | |\n- | OVS FORWARDING EXTENSION | | | | |\n- +-------------------------------+ +-----+-----------------+-----+\n- |HYPER-V Extensible Switch *#3|\n- +-----------------------------+\n- NDIS STACK\n-\n-This diagram shows the various blocks involved in the OVS Windows\n-implementation, along with some of the components available in the NDIS stack,\n-and also the virtual machines. The workflow of a packet being transmitted from\n-a VIF out and into another VIF and to a physical NIC is also shown. Later on in\n-this section, we will discuss the flow of a packet at a high level.\n-\n-The figure gives a general idea of where the OVS userspace and the kernel\n-components fit in, and how they interface with each other.\n-\n-The kernel portion (datapath) of OVS on Hyper-V solution has be implemented as\n-a forwarding extension roughly implementing the following\n-sub-modules/functionality. Details of each of these sub-components in the\n-kernel are contained in later sections:\n-\n-* Interfacing with the NDIS stack\n-\n-* Netlink message parser\n-\n-* Netlink sockets\n-\n-* Switch/Datapath management\n-\n-* Interfacing with userspace portion of the OVS solution to implement the\n- necessary functionality that userspace needs\n-\n-* Port management\n-\n-* Flowtable/Actions/packet forwarding\n-\n-* Tunneling\n-\n-* Event notifications\n-\n-The datapath for the OVS on Linux is a kernel module, and cannot be directly\n-ported since there are significant differences in architecture even though the\n-end functionality provided would be similar. Some examples of the differences\n-are:\n-\n-* Interfacing with the NDIS stack to hook into the NDIS callbacks for\n- functionality such as receiving and sending packets, packet completions, OIDs\n- used for events such as a new port appearing on the virtual switch.\n-\n-* Interface between the userspace and the kernel module.\n-\n-* Event notifications are significantly different.\n-\n-* The communication interface between DPIF and the kernel module need not be\n- implemented in the way OVS on Linux does. That said, it would be advantageous\n- to have a similar interface to the kernel module for reasons of readability\n- and maintainability.\n-\n-* Any licensing issues of using Linux kernel code directly.\n-\n-Due to these differences, it was a straightforward decision to develop the\n-datapath for OVS on Hyper-V from scratch rather than porting the one on Linux.\n-A re-development focused on the following goals:\n-\n-* Adhere to the existing requirements of userspace portion of OVS (such as\n- ovs-vswitchd), to minimize changes in the userspace workflow.\n-\n-* Fit well into the typical workflow of a Hyper-V extensible switch forwarding\n- extension.\n-\n-The userspace portion of the OVS solution is mostly POSIX code, and not very\n-Linux specific. Majority of the userspace code does not interface directly with\n-the kernel datapath and was ported independently of the kernel datapath effort.\n-\n-As explained in the OVS porting design document [6]_, DPIF is the portion of\n-userspace that interfaces with the kernel portion of the OVS. The interface\n-that each DPIF provider has to implement is defined in ``dpif-provider.h``.\n-Though each platform is allowed to have its own implementation of the\n-DPIF provider, it was found, via community feedback, that it is desired to\n-share code whenever possible. Thus, the DPIF provider for OVS on Hyper-V shares\n-code with the DPIF provider on Linux. This interface is implemented in\n-``dpif-netlink.c``.\n-\n-We'll elaborate more on kernel-userspace interface in a dedicated section\n-below. Here it suffices to say that the DPIF provider implementation for\n-Windows is netlink-based and shares code with the Linux one.\n-\n-Kernel Module (Datapath)\n-------------------------\n-\n-Interfacing with the NDIS Stack\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-For each virtual switch on Hyper-V, the OVS extensible switch extension can be\n-enabled/disabled. We support enabling the OVS extension on only one switch.\n-This is consistent with using a single datapath in the kernel on Linux. All the\n-physical adapters are connected as external adapters to the extensible switch.\n-\n-When the OVS switch extension registers itself as a filter driver, it also\n-registers callbacks for the switch/port management and datapath functions. In\n-other words, when a switch is created on the Hyper-V root partition (host), the\n-extension gets an activate callback upon which it can initialize the data\n-structures necessary for OVS to function. Similarly, there are callbacks for\n-when a port gets added to the Hyper-V switch, and an External Network adapter\n-or a VM Network adapter is connected/disconnected to the port. There are also\n-callbacks for when a VIF (NIC of a child partition) send out a packet, or a\n-packet is received on an external NIC.\n-\n-As shown in the figures, an extensible switch extension gets to see a packet\n-sent by the VM (VIF) twice - once on the ingress path and once on the egress\n-path. Forwarding decisions are to be made on the ingress path. Correspondingly,\n-we will be hooking onto the following interfaces:\n-\n-* Ingress send indication: intercept packets for performing flow based\n- forwarding.This includes straight forwarding to output ports. Any packet\n- modifications needed to be performed are done here either inline or by\n- creating a new packet. A forwarding action is performed as the flow actions\n- dictate.\n-\n-* Ingress completion indication: cleanup and free packets that we generated on\n- the ingress send path, pass-through for packets that we did not generate.\n-\n-* Egress receive indication: pass-through.\n-\n-* Egress completion indication: pass-through.\n-\n-Interfacing with OVS Userspace\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-We have implemented a pseudo device interface for letting OVS userspace talk to\n-the OVS kernel module. This is equivalent to the typical character device\n-interface on POSIX platforms where we can register custom functions for read,\n-write and ioctl functionality. The pseudo device supports a whole bunch of\n-ioctls that netdev and DPIF on OVS userspace make use of.\n-\n-Netlink Message Parser\n-~~~~~~~~~~~~~~~~~~~~~~\n-\n-The communication between OVS userspace and OVS kernel datapath is in the form\n-of Netlink messages [1]_, [7]_. More details about this are provided below. In\n-the kernel, a full fledged netlink message parser has been implemented along\n-the lines of the netlink message parser in OVS userspace. In fact, a lot of the\n-code is ported code.\n-\n-On the lines of ``struct ofpbuf`` in OVS userspace, a managed buffer has been\n-implemented in the kernel datapath to make it easier to parse and construct\n-netlink messages.\n-\n-Netlink Sockets\n-~~~~~~~~~~~~~~~\n-\n-On Linux, OVS userspace utilizes netlink sockets to pass back and forth netlink\n-messages. Since much of userspace code including DPIF provider in\n-dpif-netlink.c (formerly dpif-linux.c) has been reused, pseudo-netlink sockets\n-have been implemented in OVS userspace. As it is known, Windows lacks native\n-netlink socket support, and also the socket family is not extensible either.\n-Hence it is not possible to provide a native implementation of netlink socket.\n-We emulate netlink sockets in lib/netlink-socket.c and support all of the nl_*\n-APIs to higher levels. The implementation opens a handle to the pseudo device\n-for each netlink socket. Some more details on this topic are provided in the\n-userspace section on netlink sockets.\n-\n-Typical netlink semantics of read message, write message, dump, and transaction\n-have been implemented so that higher level layers are not affected by the\n-netlink implementation not being native.\n-\n-Switch/Datapath Management\n-~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-As explained above, we hook onto the management callback functions in the NDIS\n-interface for when to initialize the OVS data structures, flow tables etc. Some\n-of this code is also driven by OVS userspace code which sends down ioctls for\n-operations like creating a tunnel port etc.\n-\n-Port Management\n-~~~~~~~~~~~~~~~\n-\n-As explained above, we hook onto the management callback functions in the NDIS\n-interface to know when a port is added/connected to the Hyper-V switch. We use\n-these callbacks to initialize the port related data structures in OVS. Also,\n-some of the ports are tunnel ports that don't exist on the Hyper-V switch and\n-get added from OVS userspace.\n-\n-In order to identify a Hyper-V port, we use the value of 'FriendlyName' field\n-in each Hyper-V port. We call this the \"OVS-port-name\". The idea is that OVS\n-userspace sets 'OVS-port-name' in each Hyper-V port to the same value as the\n-'name' field of the 'Interface' table in OVSDB. When OVS userspace calls into\n-the kernel datapath to add a port, we match the name of the port with the\n-'OVS-port-name' of a Hyper-V port.\n-\n-We maintain separate hash tables, and separate counters for ports that have\n-been added from the Hyper-V switch, and for ports that have been added from OVS\n-userspace.\n-\n-Flowtable/Actions/Packet Forwarding\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-The flowtable and flow actions based packet forwarding is the core of the OVS\n-datapath functionality. For each packet on the ingress path, we consult the\n-flowtable and execute the corresponding actions. The actions can be limited to\n-simple forwarding to a particular destination port(s), or more commonly\n-involves modifying the packet to insert a tunnel context or a VLAN ID, and\n-thereafter forwarding to the external port to send the packet to a destination\n-host.\n-\n-Tunneling\n-~~~~~~~~~\n-\n-We make use of the Internal Port on a Hyper-V switch for implementing\n-tunneling. The Internal Port is a virtual adapter that is exposed on the Hyper-\n-V host, and connected to the Hyper-V switch. Basically, it is an interface\n-between the host and the virtual switch. The Internal Port acts as the Tunnel\n-end point for the host (aka VTEP), and holds the VTEP IP address.\n-\n-Tunneling ports are not actual ports on the Hyper-V switch. These are virtual\n-ports that OVS maintains and while executing actions, if the outport is a\n-tunnel port, we short circuit by performing the encapsulation action based on\n-the tunnel context. The encapsulated packet gets forwarded to the external\n-port, and appears to the outside world as though it was set from the VTEP.\n-\n-Similarly, when a tunneled packet enters the OVS from the external port bound\n-to the internal port (VTEP), and if yes, we short circuit the path, and\n-directly forward the inner packet to the destination port (mostly a VIF, but\n-dictated by the flow). We leverage the Windows Filtering Platform (WFP)\n-framework to be able to receive tunneled packets that cannot be decapsulated by\n-OVS right away. Currently, fragmented IP packets fall into that category, and\n-we leverage the code in the host IP stack to reassemble the packet, and\n-performing decapsulation on the reassembled packet.\n-\n-We'll also be using the IP helper library to provide us IP address and other\n-information corresponding to the Internal port.\n-\n-Event Notifications\n-~~~~~~~~~~~~~~~~~~~\n-\n-The pseudo device interface described above is also used for providing event\n-notifications back to OVS userspace. A shared memory/overlapped IO model is\n-used.\n-\n-Userspace Components\n-~~~~~~~~~~~~~~~~~~~~\n-\n-The userspace portion of the OVS solution is mostly POSIX code, and not very\n-Linux specific. Majority of the userspace code does not interface directly with\n-the kernel datapath and was ported independently of the kernel datapath effort.\n-\n-In this section, we cover the userspace components that interface with the\n-kernel datapath.\n-\n-As explained earlier, OVS on Hyper-V shares the DPIF provider implementation\n-with Linux. The DPIF provider on Linux uses netlink sockets and netlink\n-messages. Netlink sockets and messages are extensively used on Linux to\n-exchange information between userspace and kernel. In order to satisfy these\n-dependencies, netlink socket (pseudo and non-native) and netlink messages are\n-implemented on Hyper-V.\n-\n-The following are the major advantages of sharing DPIF provider code:\n-\n-1. Maintenance is simpler:\n-\n- Any change made to the interface defined in dpif-provider.h need not be\n- propagated to multiple implementations. Also, developers familiar with the\n- Linux implementation of the DPIF provider can easily ramp on the Hyper-V\n- implementation as well.\n-\n-2. Netlink messages provides inherent advantages:\n-\n- Netlink messages are known for their extensibility. Each message is\n- versioned, so the provided data structures offer a mechanism to perform\n- version checking and forward/backward compatibility with the kernel module.\n-\n-Netlink Sockets\n-~~~~~~~~~~~~~~~\n-\n-As explained in other sections, an emulation of netlink sockets has been\n-implemented in ``lib/netlink-socket.c`` for Windows. The implementation creates\n-a handle to the OVS pseudo device, and emulates netlink socket semantics of\n-receive message, send message, dump, and transact. Most of the ``nl_*``\n-functions are supported.\n-\n-The fact that the implementation is non-native manifests in various ways. One\n-example is that PID for the netlink socket is not automatically assigned in\n-userspace when a handle is created to the OVS pseudo device. There's an extra\n-command (defined in ``OvsDpInterfaceExt.h``) that is used to grab the PID\n-generated in the kernel.\n-\n-DPIF Provider\n-~~~~~~~~~~~~~\n-\n-As has been mentioned in earlier sections, the netlink socket and netlink\n-message based DPIF provider on Linux has been ported to Windows.\n-\n-Most of the code is common. Some divergence is in the code to receive packets.\n-The Linux implementation uses epoll() [8]_ which is not natively supported on\n-Windows.\n-\n-netdev-windows\n-~~~~~~~~~~~~~~\n-\n-We have a Windows implementation of the interface defined in\n-``lib/netdev-provider.h``. The implementation provides functionality to get\n-extended information about an interface. It is limited in functionality\n-compared to the Linux implementation of the netdev provider and cannot be used\n-to add any interfaces in the kernel such as a tap interface or to send/receive\n-packets. The netdev-windows implementation uses the datapath interface\n-extensions defined in ``datapath-windows/include/OvsDpInterfaceExt.h``.\n-\n-Powershell Extensions to Set ``OVS-port-name``\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-As explained in the section on \"Port management\", each Hyper-V port has a\n-'FriendlyName' field, which we call as the \"OVS-port-name\" field. We have\n-implemented powershell command extensions to be able to set the \"OVS-port-name\"\n-of a Hyper-V port.\n-\n-Kernel-Userspace Interface\n---------------------------\n-\n-openvswitch.h and OvsDpInterfaceExt.h\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-Since the DPIF provider is shared with Linux, the kernel datapath provides the\n-same interface as the Linux datapath. The interface is defined in\n-``datapath/linux/compat/include/linux/openvswitch.h``. Derivatives of this\n-interface file are created during OVS userspace compilation. The derivative for\n-the kernel datapath on Hyper-V is provided in\n-``datapath-windows/include/OvsDpInterface.h``.\n-\n-That said, there are Windows specific extensions that are defined in the\n-interface file ``datapath-windows/include/OvsDpInterfaceExt.h``.\n-\n-Flow of a Packet\n-----------------\n-\n-Figure 2 shows the numbered steps in which a packets gets sent out of a VIF and\n-is forwarded to another VIF or a physical NIC. As mentioned earlier, each VIF\n-is attached to the switch via a port, and each port is both on the ingress and\n-egress path of the switch, and depending on whether a packet is being\n-transmitted or received, one of the paths gets used. In the figure, each step n\n-is annotated as ``#n``\n-\n-The steps are as follows:\n-\n-1. When a packet is sent out of a VIF or an physical NIC or an internal port,\n- the packet is part of the ingress path.\n-\n-2. The OVS kernel driver gets to intercept this packet.\n-\n- a. OVS looks up the flows in the flowtable for this packet, and executes the\n- corresponding action.\n-\n- b. If there is not action, the packet is sent up to OVS userspace to examine\n- the packet and figure out the actions.\n-\n- c. Userspace executes the packet by specifying the actions, and might also\n- insert a flow for such a packet in the future.\n-\n- d. The destination ports are added to the packet and sent down to the Hyper-\n- V switch.\n-\n-3. The Hyper-V forwards the packet to the destination ports specified in the\n- packet, and sends it out on the egress path.\n-\n-4. The packet gets forwarded to the destination VIF.\n-\n-5. It might also get forwarded to a physical NIC as well, if the physical NIC\n- has been added as a destination port by OVS.\n-\n-Build/Deployment\n-----------------\n-\n-The userspace components added as part of OVS Windows implementation have been\n-integrated with autoconf, and can be built using the steps mentioned in the\n-BUILD.Windows file. Additional targets need to be specified to make.\n-\n-The OVS kernel code is part of a Visual Studio 2013 solution, and is compiled\n-from the IDE. There are plans in the future to move this to a compilation mode\n-such that we can compile it without an IDE as well.\n-\n-Once compiled, we have an install script that can be used to load the kernel\n-driver.\n-\n-References\n-----------\n-\n-.. [1] Hyper-V Extensible Switch https://msdn.microsoft.com/windows/hardware/drivers/network/hyper-v-extensible-switch\n-.. [2] Hyper-V Extensible Switch Extensions https://msdn.microsoft.com/windows/hardware/drivers/network/hyper-v-extensible-switch-extensions\n-.. [3] Hyper-V Extensible Switch Components https://msdn.microsoft.com/windows/hardware/drivers/network/hyper-v-extensible-switch-components\n-.. [4] Windows Filtering Platform https://msdn.microsoft.com/en-us/library/windows/desktop/aa366510(v=vs.85).aspx\n-.. [5] IP Helper https://msdn.microsoft.com/windows/hardware/drivers/network/ip-helper\n-.. [6] How to Port Open vSwitch to New Software or Hardware :doc:`porting`\n-.. [7] Netlink https://en.wikipedia.org/wiki/Netlink\n-.. [8] epoll https://en.wikipedia.org/wiki/Epoll\n","prefixes":["ovs-dev","3/5"]}