summaryrefslogtreecommitdiff
path: root/datapath-windows/ovsext/Vport.c
Commit message (Collapse)AuthorAgeFilesLines
...
* datapath-windows: return bool from NlFillOvs[Msg/Hdr]Nithin Raju2014-12-111-15/+15
| | | | | | | | | | Per review comment, in this patch, we update the return values of NlFillOvsMsg() and NlFillOvsHdr() from NTSTATUS to BOOLEAN to make them consistent with the Nl* functions. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: refactor BuildReplyMsgFromMsgIn & BuildErrorMsgNithin Raju2014-12-111-15/+13
| | | | | | | | In this patch, we consolidate code in Netlink.c. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Move Build*Msg() to Netlink.cNithin Raju2014-12-051-42/+5
| | | | | | | | | Moving the functions that build netlink messages to Netlink.c from Vport.c Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Move vport code from Datapath.c to Vport.c.Nithin Raju2014-11-241-0/+743
| | | | | | | | | | Plain code motion. No additional cleanup or refactoring peformed. I'll be doing some code refactoring in subsequent patches. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Sorin Vinturis <svinturis@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: rename 'hvDeleted' to 'isPresentOnHv'Nithin Raju2014-11-201-7/+7
| | | | | | | | | | | | | 'hvDeleted' was originally added to track vports that got deleted from the Hyper-V switch, but which still exists in OVS. Since then, it has taken a new meaning: eg. it is set to TRUE for VXLAN ports which don't exist on the Hyper-V switch at all. Hence renaming it to something more appropriate. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Sorin Vinturis <svinturis@cloudbasesolutions.com> Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
* datapath-windows: Fixes in HvCreatePort() to re-add a portNithin Raju2014-11-201-7/+62
| | | | | | | | | | | | | | | | | | | | | | In this patch, we update HvCreatePort() to be able to re-add a Hyper-V port. Specifically, we handle the case where the port had also been added by OVS userspace, so that when the port was previously deleted from Hyper-V, we did not deallocate the port. The key to a vport is its name. We lookup the list of vports both in the 'portIdHashArray' as well as 'portNoHashArray' to make sure that we don't have a port with the same name. Validation: - deleted an re-added a port with and without the corresponding OVS port existing - deleted, changed the name of a port, and re-added it back with and without the corresponding OVS port existing. - uninstall was succcessful. No asserts hit. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
* datapath-windows: Changes to InitOvsVportCommon()Nithin Raju2014-11-201-10/+18
| | | | | | | | | | | | | | | | | If a Hyper-V port (for which there exists an OVS port), gets deleted and re-added, we'll call into InitOvsVportCommon() for the port to insert the port into the 'portIdHashArray' as well as do a few other initialization in the switch ocntext. We should not be incrementing 'numHvPorts' at this point since this vport has been counted before when it was first allocated. To account for this, we add a new parameter to InitOvsVportCommon(). The arguments passed by some of the callers are not 100% correct, and will be fixed in future commit in the series. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
* datapath-windows: Changes to OvsRemoveAndDeleteVport()Nithin Raju2014-11-201-23/+73
| | | | | | | | | | | | | | | | In this patch, we add changes to OvsRemoveAndDeleteVport() to allow the caller to specify if a vport is being deleted because it got deleted on Hyper-V or if it got deleted from OVS userspace. The reason we need to make the distinction is to be able to delete the vport from the relevant hash tables. If a port has been deleted from all the hash tables ie. has been deleted from Hyper-V as well as OVS userspace, it gets deallocated. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
* datapath-windows: add WCHAR version of OvsFindVportByHvName()Nithin Raju2014-11-201-14/+26
| | | | | | | | | | | | | | In this patch, we rename the existing OvsFindVportByHvName() to OvsFindVportByHvNameA() to indicate that the input string is an ASCII string. We also define a OvsFindVportByHvNameW() that takes as input a WCHAR string. This will be used later in HvCreatPort() to check for ports with duplicate names. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
* datapath-windows: fixes in OvsGetExtInfoIoctl()Nithin Raju2014-11-201-2/+14
| | | | | | | | A few fixes around locking. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
* datapath-windows: Remove all duplicate checks for NULL.Sorin Vinturis2014-11-141-4/+0
| | | | | | | | | | | | Right now the gOvsSwitchContext pointer is checked against NULL in a lot of places of the OVS extension code. This check should be done only once to avoid wasteful checks. Thus I have added the check in the dispatch routine, before doing any processing, and removed all other checks from the rest of the code. Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Update port property.Eitan Eliahu2014-11-121-0/+57
| | | | | | | | | | | | | | | | Update Hyper-V port properties on NDIS property port set callback. Driver update the port friendly name in its internal table. Since the NIC Create callback won't be called after we need to maintain the NIC and THE OVS states of the Vport. Setting a new friendly name was tested in the following states: [1] The port is disconnected [2] The port is connected but not OVS user mode counter port [3] The port is connected and an OCS port associated with it Signed-off-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Fix locking code in OvsGetNetdevCmdHandler().Nithin Raju2014-10-311-5/+0
| | | | | | | | We were acquiring locks twice, and forgotten to release a lock in an error case. Signed-off-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Nuke USE_NEW_VPORT_ADD_WORKFLOW.Nithin Raju2014-10-311-15/+0
| | | | | | | | | We were using USE_NEW_VPORT_ADD_WORKFLOW while transitioning from old workflow for adding ports. We don't need it anymore. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: OvsFindVportByPortIdAndNicIndex() and external port.Nithin Raju2014-10-281-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We use OvsFindVportByPortIdAndNicIndex() to lookup the vport for a packte received from the Hyper-V switch. If a packet was indeed received from the virtual external NIC, we should flag it. Validation: 1. Install and Uninstall the OVS EXT Driver (without enabling the OVS extension on the Hyper-V switch). 2. Install and Uninstall the OVS EXT Driver (with enabling the OVS extension on the Hyper-V switch). Hyper-V switch had a few ports. 3. Install and Uninstall the OVS EXT Driver (with enabling the OVS extension on the Hyper-V switch). Added a few ports before uninstalling. 4. Install the OVS EXT driver, and test the following functionality: a) ping between 2 VMs on the same host b) ping between 2 VMs on 2 Hyper-Vs - one physical and another virtual backed by VLAN (patch port between br-pif and br-int). c) ping between 2 VMs on 2 Hyper-Vs - one physical and another virtual backed by VXLAN. d) Successful uninstallation after these tests. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Update vport add code.Nithin Raju2014-10-281-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this patch, we make the following updates to the vport add code: 1. Clarify the roles of the different hash tables, so it is easier to read/write code in the future. 2. Update OvsNewVportCmdHandler() to support adding bridge-internal ports. 3. Fixes in OvsNewVportCmdHandler() to support adding external port. Earlier, we'd hit ASSERTs. 4. I could not figure out way to add a port of type OVS_PORT_TYPE_INTERNAL with name "internal" to the confdb using ovs-vsctl.exe. And, this is needed in order to add the Hyper-V internal port from userspace. To workaround this problem, we treat a port of type OVS_PORT_TYPE_NETDEV with name "internal" as a request to add the Hyper-V internal port. This is a workaround. The end result is that there's a discrepancy between the port type in the datpaath v/s confdb, but this has not created any trouble in testing so far. If this ends up becoming an issue, we can mark the Hyper-V internal port to be of type OVS_PORT_TYPE_NETDEV. No harm. 5. Because of changes indicated in #1, we also update the vport dump code to look at the correct hash table for ports added from userspace. 6. Add a OvsGetTunnelVport() for convenience. 7. Update ASSERTs() while cleaning up the switch. 8. Nuke OvsGetExternalVport() and OvsGetExternalMtu(). Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Refactor core in Vport.c.Nithin Raju2014-10-281-38/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | We do a bunch of changes that did not make sense to split up into smaller patches: 1. Add descriptive comments to the important functions to clarify purpose. 2. s/OvsInitVportCommon/InitHvVportCommon - this function is common code for every port that shows up on the Hyper-V switch. 3. Introduce a InitOvsVportCommon() that is common code for evrey port that gets added from userspace. This is especially useful for ports that are not present on the Hyper-V switch. ie. tunnel ports and bridge-internal ports. 4. Fix OvsClearAllSwitchVports() to remove ports from both the lists: the ones added from Hyper-V as well as the ones added from OVS userspace. 5. Update OvsInitVxlanTunnel() to not call into InitHvVportCommon (formerly OvsInitVportCommon()) since it is not a port on the Hyper-v switch. In a later patch in the series, we'll call InitOvsVportCommon() for a VXLAN port. 6. 'numNonHvVports' increments and decrements ONLY for ports that are added from OVS userspace but not present on the Hyper-V switch. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: OvsInitTunnelVport() and OvsInitBridgeInternalVport().Nithin Raju2014-10-281-2/+49
| | | | | | | | | | In this patch, we add the init functions for a Tunnel vport and a Bridge-internal vport. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Clarify externalVport.Nithin Raju2014-10-281-12/+12
| | | | | | | | | | | | | | In this patch, we add some explanation about the usage of 'externalVport' in the switch context. Also, we rename 'externalVport' to 'virtualExternalVport' in alignment with the explanation. Also, we rename 'numVports' to 'numHvVports' since ports are added from 2 ends now. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: loop iterator fixes in Vport.cNithin Raju2014-10-131-3/+4
| | | | | | | | | | | | | Validation: - With these fixes, we no longer see the freeze during module uninstallation or when we try to add a new port. - We are able to add a port called "internal of type internal using: ovs-dpctl.exe add-if ovs-system internal,type=internal Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: delete ports from portIdHashArray during cleanupNithin Raju2014-10-131-4/+4
| | | | | | | Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Add netlink command vport deleteNithin Raju2014-10-131-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deletion of a vport is now handled both by the netlink command vport delete and the hyper-v switch port delete handler. If a netlink command vport delete is requested on a vport that has no hyper-v switch port counterpart (i.e., it is a tunnel port, or or the hyper-v switch virtual nic is disconnected), the vport is deleted and removed. If the hyper-v switch port delete is requested (i.e. the VNic is disconnecting) and the ovs (datapath) part is deleted (i.e. was deleted by netlink command vport delete, or was never created by an netlink command vport new), then the hyper-v switch port delete function handler deletes and removes the vport. If the hyper-v switch port delete is requested while its datapath counterpart is still alive, or, when the netlink command vport delete is requested while the hyper-v switch port is still alive, the port is only marked that it's part is deleted - the field hvDeleted was added to OVS_VPORT_ENTRY to specify if the hyper-v switch port side was deleted; if the ovs (datapath) port number is invalid, then it means that the ovs (datapath) side of the port is deleted (or, not created). Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Acked-by: Nithin Raju <nithin@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Add netlink command: vport newNithin Raju2014-10-131-47/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Does the following: a. before creating the vport, makes sure there is no existing vport with the same ovs (datapath) port name. If this is not so, it means that the specified port already exists: it returns NL_ERROR_EXIST. b. looks up the vport: o) if the vport type is "internal", then the internal vport of the hyper-v switch is yielded. o) if the vport type is "netdev" and the vport ovs (datapath) name is "external", then the external vport is yielded. The switch can have only one "external" vport. The method of looking up the "external" port can be changed later, if a better method is found. o) if the vport type is "netdev" but the name is not "external", then a VM VNic is assumed, so the vport is looked up by hyper-v switch port friendly name. o) if none of the above, a tunneling vport type is expected, which in our case, at the moment, can only be the one vxlan vport. Only one vxlan vport is allowed, and it's saved in switchContext->vxlanVport. The tunneling vport is the only kind which is created in the netlink command vport new, because it does not have a hyper-v switch port counterpart. c. if the vport could not be found (non-tunneling vports), then the NL_ERROR_INVAL is returned to the userspace. d. if the vport was found, but it has a valid ovs (datapath) port number, it means that this port was already created by a netlink command vport new. Therefore, NL_ERROR_EXIST is returned to the userspace. e. if the netlink command vport new specified an ovs (datapath) port number, then it means that the userspace is trying to re-create a vport: that specified port number will be used. Otherwise, a new ovs (datapath) port number is computed and assigned to the vport. f. the ovsName field of the vport is set to the name given by the OVS_VPORT_ATTR_NAME netlink attribute. The ovsNameLen is no longer stored in the OVS_VPORT_ENTRY struct, because ovsName is null-terminated. g. the "portOptions" are set to the vport, if the attribute OVS_VPORT_ATTR_OPTIONS was given. Otherwise, it is set to NULL. portOptions is a PNL_ATTR, which is yet to be implemented. The only option available for now would be vxlan udp destination port, but we have a constant value there, so this option is not yet needed. h. the upcall pid is set to the vport. i. if the vport type is vxlan, then the vport pointer is also saved to switchContext->vxlanVport. j. Now that the ovs (datapath) port number and the ovs name were set, the vport can be added to the hash array of vports, hashed on ovs name and to the hash array of vports hashed by ovs (datapath) port number. k. the reply is yielded to the userspace. Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Acked-by: Nithin Raju <nithin@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Add port friendly name to OVS_VPORT_ENTRYAlin Serdean2014-10-091-2/+56
| | | | | | | | | | | | | | | | | The port friendly name will be set by WMI / powershell script. It will be used from within the netlink command vport new to identify the hyper-v switch port it represents. This patch also adds a function to lookup a vport by the port friendly name. Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Tested-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Make VPORT ovs number values smaller than MAXUINT16Alin Serdean2014-10-091-123/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For this, the old method of finding vports based on the ovs port numbers is removed. Now, the lookup of a vport by ovs port number is done the same way as the lookup by hyper-v switch port id. This is done so that the kernel is able to interact with the userspace correctly when using vport channels. The problem manifested in lib/dpif-netlink.c, at the function vport_add_channels. This patch removes the field vportArray from OVS_SWITCH_CONTEXT. In its place, portNoHashArray is set. In the OVS_VPORT_ENTRY struct, we also add portNoLink. This new method will do lookup and insertions of vports by ovs (datapath) port numbers the same way it is done for hyper-v switch port ids. This patch implicitly removes the indexes, which were previously used in insertions and lookups on ovs port numbers. The removal of the index also means that the vxlan vport can no longer be looked up the same way as it was done before: now we hold a pointer to it, vxlanVport in OVS_SWITCH_CONTEXT. For the moment, we can have only one vxlan vport. When more will be allowed, this field will turn into a list of vxlan ports. The invalid port number value (held in OVS_DPPORT_NUMBER_INVALID) is now changed from 0 to MAXUINT16, the same as it is on linux. The function OvsComputeVportNo has also been removed, since the computation of a vport port number can no longer be done like this. When vport add will be added, a new, updated OvsComputeVportNo function will be added. Also, in OvsInitVportCommon, we no longer need to (and no longer can) initialize vport->ovsName, nor vport->ovsNameLen, because they will be initialized by the netlink command vport add. Since the netlink command vport add will generate numbers for the datapath (ovs) port numbers and set the port names, we cannot insert the vport into the hash array of port numbers here, nor into the hash array of port names. Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Tested-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Rename switch context's portHashArray and vport's portLinkAlin Serdean2014-10-091-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The field portLink of the OVS_VPORT_ENTRY is the link within the OVS_SWITCH_CONTEXT's hash array of vports portHashArray, hashed by the portId field of the OVS_VPORT_ENTRY. Later on, we will need to modify the OVS_VPORT_ENTRY so that its port numbers are set to maximum MAXUINT16. This will require that the field vportArray of OVS_SWITCH_CONTEXT be removed and replaced with a hash array, portNoHashArray. Also, a new field, portNoLink, will need to be added to OVS_VPORT_ENTRY. In order to differentiate between portHashArray and portNoHashArray, portHashArray is renamed to portIdHashArray. Also, in order to differentiate between portLink and portNoLink, portLink is renamed to portIdLink. In a future patch the vport functionality will be changed to constraint the port numbers to MAXUINT16. Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Tested-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Rename switch context's nameHashArray and vport's nameLink ↵Alin Serdean2014-10-091-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | login register The field nameLink of the OVS_VPORT_ENTRY is the link within the OVS_SWITCH_CONTEXT's hash array of vports nameHashArray, hashed by the ovsName field of the OVS_VPORT_ENTRY. Later on, the friendly name of the hyper-v switch port will need to be set from userspace using WMI. This will require that the hyper-v switch port friendly name be set to the exact string value as the ovs (datapath) port name set from netlink command vport add. The vport will need to differentiate between the ovs (datapath) port name and hyper-v switch port friendly name, because they may differ in erroneous scenarios, or state differences between the hyper-v switch port and the ovs (datapath) port. This may happen if the vport was created by the netlink command vport add, but the VM disconnected (i.e. the hyper-v switch port was later deleted). Storing another field in vport, "portFriendlyName" would normally make the current switchContext->nameHashArray and vport->nameLink confusing since the "name"-s may be understood to mean the hyper-v switch port friendly name, or the hyper-v switch port name, when it actually refers to the ovs (datapath) port name. Hence, the variable nameHashArray is renamed to ovsPortNameHashArray, while the nameLink is renamed to ovsPortNameLink. This change will make a clearer connection between these and the vport field "ovsName" to which they revolve around. Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Tested-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Rename OvsGetVportNo into OvsComputeVportNo and make publicAlin Serdean2014-10-091-9/+6
| | | | | | | | | | | | | | | | | | | | | OvsGetVportNo computes a new port number. Therefore, OvsComputeVportNo is a more clear name for what the function does. Reading OvsGetVportNo may give the false impression that it returns the port number of an existing vport. Also, since the responsibility of assigning dp port numbers no longer falls on the hyper-v switch port handlers side, but on the netlink vport commands side (vport add), we will need to use this compute port number function from outside Vport.c. Therefore, this function declaration is moved from Vport.c to Vport.h, and becomes public. Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Tested-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Define OVS_DPPORT_NUMBER_INVALIDAlin Serdean2014-10-091-1/+1
| | | | | | | | | | | | | | | | | | | The fields externalVport and internalVport of the OVS_SWITCH_CONTEXT struct are currently defined as PVOID. However, all over the code they are used as POVS_VPORT_ENTRY. In order to improve clarity and reduce the need for useless casts to POVS_VPORT_ENTRY, this patch changes the type from PVOID to POVS_VPORT_ENTRY. This patch does not cleanup the code that already uses casts to POVS_VPORT_ENTRY. This cleanup can be done later on as well. Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Tested-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: We don't need to keep validation ports in ovsAlin Serdean2014-10-091-3/+5
| | | | | | | | | | | | | | | Validation ports are used internally by the hyper-v switch to validate and verify settings for the real hyper-v switch ports that will be connected to the VNic. The validation ports are of no use to us - we must skip handling them, and return STATUS_SUCCESS as the OID result. Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Tested-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Rename hyper-v switch port and nic handlersAlin Serdean2014-10-091-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | Functions such as OvsCreatePort are vague in regard to who creates it or when. It wasn't a problem thus far, since the vports were created, updated and destroyed from one place only (hyper-v switch part). But now, with the netlink implementation of the vport commands, a part of the vport is constructed by the netlink vport add, and the other part is constructed by the hyper-v switch nic and port handlers. This patch renames the hyper-v switch nic and port handlers, so that they are now prefixed by "Hv" instead of "Ovs", in order to clarify which of the functions are nic or port handlers. This will make more clear the usages from netlink vport commands side and from hyper-v switch side. It will also make more obvious which nic and port functions are helper functions. Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Tested-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Remove the old IOCTL vport functions.Alin Serdean2014-10-091-276/+0
| | | | | | | | | | | | | The old IOCTL vport functions (using the non-netlink device) are no longer needed. They should be removed. Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Tested-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Update OvsGetExtInfoIoctl() to the new vport add workflowNithin Raju2014-10-091-9/+24
| | | | | | | | | | | | | | | | | I applied the patches for the new vport add workflow that is out for review, and found that some of the existing code in OvsGetExtInfoIoctl() needs to be updated. In this patch, we add a CPP called USE_NEW_VPORT_ADD_WORKFLOW and add the fixes under USE_NEW_VPORT_ADD_WORKFLOW == 1. The current value is set to 0, since the vport add code is not checked in yet. Sending out this patch to unblock the vport add code when it gets checked in. There are other fixes also required, but they are being addressed as part of the review comments for vport-add. Signed-off-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
* datapath-windows: implementation of netdev commandsNithin Raju2014-10-061-59/+183
| | | | | | | | | | | | validation: - Vport dump works now without printing any errors. I didn't go so far as to test if vport add works. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: Add stub handlers for netdev commandsNithin Raju2014-10-061-0/+14
| | | | | | | | | | In this patch, we add stub handlers for the netdev commands. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Ankur Sharma <ankursharma@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* datapath-windows: fix OVS_VPORT_TYPESamuel Ghinet2014-09-261-40/+41
| | | | | | | | | | | | | | | | | The windows ovs kernel uses an OVS_VPORT_TYPE enum that is incompatible with the userspace counterpart (enum ovs_vport_type from openvswitch.h). We must use the same enum type for the netlink communication to work properly. This patch makes the fix: "typedef enum ovs_vport_type OVS_VPORT_TYPE" and changes the afferent kernel driver code: o) vport types synthetic and emulated turn to: netdev o) vport type internal turns to: internal o) vport type external truns to: netdev (plus, we hold a field in vport, "isExternal" Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.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/+1415
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>
View Lorry Controller Status