[ovs-dev] Report
The message could not be delivered ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Open Vswitch Feature Enhancement- Provider Bridging Feature
Hi Team, We are thinking to contibute in following feature ; -IEEE 802.1ah (Provider Backbone Bridging). If anybody is already working on it please let us know. Thanks Regards, Hiteshi Madan -Hiteshi Madan/DEL/TCS wrote: - To: Ben Pfaff b...@nicira.com From: Hiteshi Madan/DEL/TCS Date: 09/24/2014 01:04PM Cc: dev@openvswitch.org Subject: Re: Open Vswitch Feature Enhancement- Provider Bridging Feature Hi Thomas, While working on 802.1ad feature(provider bridging),will you also incorporate IEEE 802.1ah (Provider Backbone Bridging)? Can we Plan to implement IEEE 802.1ah (Provider Backbone Bridging) feature separtely? Thanks Regards, Hiteshi Madan -Ben Pfaff b...@nicira.com wrote: - To: Hiteshi Madan hiteshi.ma...@tcs.com, Thomas F Herbert thomasfherb...@gmail.com From: Ben Pfaff b...@nicira.com Date: 09/02/2014 08:48PM Cc: dev@openvswitch.org Subject: Re: Open Vswitch Feature Enhancement- Provider Bridging Feature On Mon, Sep 01, 2014 at 05:16:49PM +0530, Hiteshi Madan wrote: Hi Ben and Team, I have checked the features list supported in open Vswitch.I found that following feature is not yet supported: ?-??? 802.1ad (provider bridging) We are thinking to contribute in above feature. Can you please provide your inputs/opinions and suggestion for it? Also can you please provide any documents link which can help us to understand the code flow in faster way? Please coordinate with Tom Herbert (CCed), who is also working on an implementation. =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Bug#763428: Bug#763428: openvswitch-switch: openvswitch doesn't work anymore since kernel 3.16 update
On Wed, 8 Oct 2014 13:02:42 -0700 Ben Pfaff b...@nicira.com wrote: I can't reproduce this problem with OVS master and upstream kernel 3.16, or with OVS branch-2.3 on the commit from which the Debian packages were made. Now I'm downloading a Debian ISO so that I can try it with the exact kernel and OVS packaging against which the bug was reported. Hi, Did you manage to reproduce the bug with debian ISO? Thanks for your time, Laurent ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Jobs Opportunities in France/Canada
Jobs Opportunities in France/Canada This letter is to inform you on behalf of the management of EVANS HOTEL Suites Paris France, that the hotel needs able men and women, married and not married who are willing to relocate to France in order to fill various slots in the available jobs/vacancies in their hotels. Accountant, accounting clerk * minimum education requires:- diploma certificate * skills requires: - record-keeping , project organization, computer literacy Barkeeper, bartender * minimum education requires:- high school certificate * skills requires: - dealing with the public, customer service Cleaner, car wash, laundry * minimum education requires:- any * skills requires: - care and hard working Customer services, reservation agents * minimum education requires:- diploma * skills requires: - dealing with the public,English/French, computer skills Master chef, meat - poultry fish chef, pasta chef, sauce chef * minimum education requires:- certificate * skills requires: - serving, customer service, Busing, estimating amounts Apprentice cook, grill cook, short order cook * minimum education requires:- trained cook * skills requires: cooking, serving Host, hostess, waiter, waitress * minimum education requires:- high school certificate * skills requires: - dealing with the public,English/French Food service supervisors * minimum education requires:- high school certificate * skills requires: - customer service , communication skills ,English/French Sales administrator, sales person, retail sales clerk * minimum education requires:- high school certificate * skills requires: - dealing with the public, customer service, product Knowledge Hotel nurses * minimum education requires:- certificate * skills requires: - minimum 2 years experience Store keeper, store keeper supervisor * minimum education requires:- high school certificate * skills requires: - dealing with the public, customer service, product Knowledge Receptionist, secretary, hotel front desk, clerks * minimum education requires:- high school certificate * skills requires: - dealing with the public, customer service, scheduling Electronics technicians, computer engineer * minimum education requires:- certificate * skills requires: - customer service Dj , dancers , musicians * minimum education requires:- any * skills requires: - professional Day / night security guard * minimum education requires:- high school * skills requires: - trained, strong and intelligent Computer operator , graphic designer * minimum education requires:- certificate * skills requires: - professional computer literacy The hotel management will take care of your accommodation flight ticket to France or Canada any where the management which to post you for service. Requirements * color passport photograph * cv/resume (English OR French) interested applicant should click on reply to Contact EVANS HOTEL management. Mr. Mario Costa Email:- applicetionoff...@job4u.com Tel: +33 605 734 438 / Fax: + 33 160 54177 42 20 Avenue Victoria 75001 Paris France We wish you good luck! Sincerely, Ms.Myrna Kilcrease France/Canada Foreign Workers Services Email:- info.kilcre...@gmail.com ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Jobs Opportunities in France/Canada
Jobs Opportunities in France/Canada This letter is to inform you on behalf of the management of EVANS HOTEL Suites Paris France, that the hotel needs able men and women, married and not married who are willing to relocate to France in order to fill various slots in the available jobs/vacancies in their hotels. Accountant, accounting clerk * minimum education requires:- diploma certificate * skills requires: - record-keeping , project organization, computer literacy Barkeeper, bartender * minimum education requires:- high school certificate * skills requires: - dealing with the public, customer service Cleaner, car wash, laundry * minimum education requires:- any * skills requires: - care and hard working Customer services, reservation agents * minimum education requires:- diploma * skills requires: - dealing with the public,English/French, computer skills Master chef, meat - poultry fish chef, pasta chef, sauce chef * minimum education requires:- certificate * skills requires: - serving, customer service, Busing, estimating amounts Apprentice cook, grill cook, short order cook * minimum education requires:- trained cook * skills requires: cooking, serving Host, hostess, waiter, waitress * minimum education requires:- high school certificate * skills requires: - dealing with the public,English/French Food service supervisors * minimum education requires:- high school certificate * skills requires: - customer service , communication skills ,English/French Sales administrator, sales person, retail sales clerk * minimum education requires:- high school certificate * skills requires: - dealing with the public, customer service, product Knowledge Hotel nurses * minimum education requires:- certificate * skills requires: - minimum 2 years experience Store keeper, store keeper supervisor * minimum education requires:- high school certificate * skills requires: - dealing with the public, customer service, product Knowledge Receptionist, secretary, hotel front desk, clerks * minimum education requires:- high school certificate * skills requires: - dealing with the public, customer service, scheduling Electronics technicians, computer engineer * minimum education requires:- certificate * skills requires: - customer service Dj , dancers , musicians * minimum education requires:- any * skills requires: - professional Day / night security guard * minimum education requires:- high school * skills requires: - trained, strong and intelligent Computer operator , graphic designer * minimum education requires:- certificate * skills requires: - professional computer literacy The hotel management will take care of your accommodation flight ticket to France or Canada any where the management which to post you for service. Requirements * color passport photograph * cv/resume (English OR French) interested applicant should click on reply to Contact EVANS HOTEL management. Mr. Mario Costa Email:- applicetionoff...@job4u.com Tel: +33 605 734 438 / Fax: + 33 160 54177 42 20 Avenue Victoria 75001 Paris France We wish you good luck! Sincerely, Ms.Myrna Kilcrease France/Canada Foreign Workers Services Email:- info.kilcre...@gmail.com ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 6/6] datapath-windows: loop iterator fixes in Vport.c
Acked-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com
Tested-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Nithin Raju
Trimis: Monday, October 13, 2014 6:56 AM
Către: dev@openvswitch.org
Subiect: [ovs-dev] [PATCH 6/6] datapath-windows: loop iterator fixes in Vport.c
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 nit...@vmware.com
---
datapath-windows/ovsext/Vport.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/datapath-windows/ovsext/Vport.c b/datapath-windows/ovsext/Vport.c
index 9dfbf51..0522cfd 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -512,16 +512,17 @@ OvsFindVportByHvName(POVS_SWITCH_CONTEXT switchContext,
/* 'portFriendlyName' is not NUL-terminated. */
SIZE_T length = strlen(name);
SIZE_T wstrSize = length * sizeof(WCHAR);
+UINT i;
PWSTR wsName = OvsAllocateMemory(wstrSize);
if (!wsName) {
return NULL;
}
-for (UINT i = 0; i length; i) {
+for (i = 0; i length; i++) {
wsName[i] = name[i];
}
-for (UINT32 i = 0; i OVS_MAX_VPORT_ARRAY_SIZE; i) {
+for (i = 0; i OVS_MAX_VPORT_ARRAY_SIZE; i++) {
head = (switchContext-portIdHashArray[i]);
LIST_FORALL(head, link) {
vport = CONTAINING_RECORD(link, OVS_VPORT_ENTRY, portIdLink); @@
-912,7 +913,7 @@ cleanup:
VOID
OvsClearAllSwitchVports(POVS_SWITCH_CONTEXT switchContext) {
-for (UINT hash = 0; hash OVS_MAX_VPORT_ARRAY_SIZE; hash) {
+for (UINT hash = 0; hash OVS_MAX_VPORT_ARRAY_SIZE; hash++) {
PLIST_ENTRY head, link, next;
head = (switchContext-portIdHashArray[hash OVS_VPORT_MASK]);
--
1.7.4.1
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 1/6] datapath-windows: Add netlink command: vport new
Acked-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com
Tested-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Nithin Raju
Trimis: Monday, October 13, 2014 6:56 AM
Către: dev@openvswitch.org
Cc: Samuel Ghinet
Subiect: [ovs-dev] [PATCH 1/6] datapath-windows: Add netlink command: vport new
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 sghi...@cloudbasesolutions.com
Acked-by: Nithin Raju nit...@vmware.com
Acked-by: Ankur Sharma ankursha...@vmware.com
Acked-by: Eitan Eliahu elia...@vmware.com
---
datapath-windows/ovsext/Datapath.c | 238 +++-
datapath-windows/ovsext/Vport.c| 69 ---
datapath-windows/ovsext/Vport.h| 18 +++-
datapath-windows/ovsext/Vxlan.c| 48 +---
datapath-windows/ovsext/Vxlan.h|4 +-
5 files changed, 301 insertions(+), 76 deletions(-)
diff --git a/datapath-windows/ovsext/Datapath.c
b/datapath-windows/ovsext/Datapath.c
index 04b34e4..e55f29d 100644
--- a/datapath-windows/ovsext/Datapath.c
+++ b/datapath-windows/ovsext/Datapath.c
@@ -33,6 +33,7 @@
#include NetProto.h
#include Flow.h
#include User.h
+#include Vxlan.h
#ifdef OVS_DBG_MOD
#undef OVS_DBG_MOD
@@ -93,7 +94,8 @@ static NetlinkCmdHandler OvsGetPidCmdHandler,
OvsNewDpCmdHandler,
OvsGetDpCmdHandler,
OvsSetDpCmdHandler,
- OvsGetVportCmdHandler;
+ OvsGetVportCmdHandler,
+ OvsNewVportCmdHandler;
NetlinkCmdHandlerOvsGetNetdevCmdHandler;
@@ -192,6 +194,11 @@ NETLINK_CMD nlVportFamilyCmdOps[] = {
.supportedDevOp = OVS_WRITE_DEV_OP | OVS_READ_DEV_OP |
OVS_TRANSACTION_DEV_OP,
.validateDpIndex = TRUE
+},
+{ .cmd = OVS_VPORT_CMD_NEW,
+ .handler = OvsNewVportCmdHandler,
+ .supportedDevOp = OVS_TRANSACTION_DEV_OP,
+ .validateDpIndex = TRUE
}
};
@@ -1555,6 +1562,9 @@ OvsGetVport(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
POVS_MESSAGE msgOut = (POVS_MESSAGE)usrParamsCtx-outputBuffer;
POVS_VPORT_ENTRY vport = NULL;
NL_ERROR nlError = NL_ERROR_SUCCESS;
+PCHAR portName = NULL;
+UINT32 portNameLen = 0;
+UINT32 portNumber =
Re: [ovs-dev] [PATCH 5/6] datapath-windows: delete ports from portIdHashArray during cleanup
Acked-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com
Tested-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Nithin Raju
Trimis: Monday, October 13, 2014 6:56 AM
Către: dev@openvswitch.org
Subiect: [ovs-dev] [PATCH 5/6] datapath-windows: delete ports from
portIdHashArray during cleanup
Signed-off-by: Nithin Raju nit...@vmware.com
---
datapath-windows/ovsext/Vport.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/datapath-windows/ovsext/Vport.c b/datapath-windows/ovsext/Vport.c
index 61fa71d..9dfbf51 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -913,12 +913,12 @@ VOID
OvsClearAllSwitchVports(POVS_SWITCH_CONTEXT switchContext) {
for (UINT hash = 0; hash OVS_MAX_VPORT_ARRAY_SIZE; hash) {
-PLIST_ENTRY head, link;
+PLIST_ENTRY head, link, next;
-head = (switchContext-portNoHashArray[hash OVS_VPORT_MASK]);
-LIST_FORALL(head, link) {
+head = (switchContext-portIdHashArray[hash OVS_VPORT_MASK]);
+LIST_FORALL_SAFE(head, link, next) {
POVS_VPORT_ENTRY vport;
-vport = CONTAINING_RECORD(link, OVS_VPORT_ENTRY, portNoLink);
+vport = CONTAINING_RECORD(link, OVS_VPORT_ENTRY,
+ portIdLink);
OvsRemoveAndDeleteVport(switchContext, vport);
}
}
--
1.7.4.1
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 4/6] datpath-windows: pass NDIS_RWL_AT_DISPATCH_LEVEL instead of BOOLEAN
Acked-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com
Tested-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Nithin Raju
Trimis: Monday, October 13, 2014 6:56 AM
Către: dev@openvswitch.org
Subiect: [ovs-dev] [PATCH 4/6] datpath-windows: pass NDIS_RWL_AT_DISPATCH_LEVEL
instead of BOOLEAN
In 'OvsAcquireDatapathRead()' and 'OvsAcquireDatapathWrite()', we seem to be
passing a BOLEAN instead of NDIS_RWL_AT_DISPATCH_LEVEL.
Signed-off-by: Nithin Raju nit...@vmware.com
---
datapath-windows/ovsext/Switch.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/datapath-windows/ovsext/Switch.h b/datapath-windows/ovsext/Switch.h
index 4591c11..ac708b7 100644
--- a/datapath-windows/ovsext/Switch.h
+++ b/datapath-windows/ovsext/Switch.h
@@ -138,7 +138,8 @@ OvsAcquireDatapathRead(OVS_DATAPATH *datapath,
BOOLEAN dispatch) {
ASSERT(datapath);
-NdisAcquireRWLockRead(datapath-lock, lockState, dispatch);
+NdisAcquireRWLockRead(datapath-lock, lockState,
+ dispatch ? NDIS_RWL_AT_DISPATCH_LEVEL : 0);
}
static __inline VOID
@@ -147,7 +148,8 @@ OvsAcquireDatapathWrite(OVS_DATAPATH *datapath,
BOOLEAN dispatch) {
ASSERT(datapath);
-NdisAcquireRWLockWrite(datapath-lock, lockState, dispatch);
+NdisAcquireRWLockWrite(datapath-lock, lockState,
+ dispatch ? NDIS_RWL_AT_DISPATCH_LEVEL : 0);
}
--
1.7.4.1
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/6] datapath-windows: Add netlink command vport delete
Acked-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com
Tested-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Nithin Raju
Trimis: Monday, October 13, 2014 6:56 AM
Către: dev@openvswitch.org
Cc: Samuel Ghinet
Subiect: [ovs-dev] [PATCH 2/6] datapath-windows: Add netlink command vport
delete
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 sghi...@cloudbasesolutions.com
Acked-by: Nithin Raju nit...@vmware.com
Acked-by: Ankur Sharma ankursha...@vmware.com
Acked-by: Eitan Eliahu elia...@vmware.com
---
datapath-windows/ovsext/Datapath.c | 112 +++-
datapath-windows/ovsext/Vport.c| 21 +--
2 files changed, 126 insertions(+), 7 deletions(-)
diff --git a/datapath-windows/ovsext/Datapath.c
b/datapath-windows/ovsext/Datapath.c
index e55f29d..19c0834 100644
--- a/datapath-windows/ovsext/Datapath.c
+++ b/datapath-windows/ovsext/Datapath.c
@@ -95,7 +95,8 @@ static NetlinkCmdHandler OvsGetPidCmdHandler,
OvsGetDpCmdHandler,
OvsSetDpCmdHandler,
OvsGetVportCmdHandler,
- OvsNewVportCmdHandler;
+ OvsNewVportCmdHandler,
+ OvsDeleteVportCmdHandler;
NetlinkCmdHandlerOvsGetNetdevCmdHandler;
@@ -199,7 +200,12 @@ NETLINK_CMD nlVportFamilyCmdOps[] = {
.handler = OvsNewVportCmdHandler,
.supportedDevOp = OVS_TRANSACTION_DEV_OP,
.validateDpIndex = TRUE
-}
+},
+{ .cmd = OVS_VPORT_CMD_DEL,
+ .handler = OvsDeleteVportCmdHandler,
+ .supportedDevOp = OVS_TRANSACTION_DEV_OP,
+ .validateDpIndex = TRUE
+},
};
NETLINK_FAMILY nlVportFamilyOps = {
@@ -1880,6 +1886,108 @@ Cleanup:
return STATUS_SUCCESS;
}
+
+static NTSTATUS
+OvsDeleteVportCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
+ UINT32 *replyLen) {
+NDIS_STATUS status = STATUS_SUCCESS;
+LOCK_STATE_EX lockState;
+
+POVS_MESSAGE msgIn = (POVS_MESSAGE)usrParamsCtx-inputBuffer;
+POVS_MESSAGE msgOut = (POVS_MESSAGE)usrParamsCtx-outputBuffer;
+POVS_VPORT_ENTRY vport = NULL;
+NL_ERROR nlError = NL_ERROR_SUCCESS;
+PSTR portName = NULL;
+UINT32 portNameLen = 0;
+
+static const NL_POLICY ovsVportPolicy[] = {
+[OVS_VPORT_ATTR_PORT_NO] = { .type = NL_A_U32, .optional = TRUE },
+[OVS_VPORT_ATTR_NAME] = { .type = NL_A_STRING, .maxLen = IFNAMSIZ,
.optional = TRUE },
+};
+PNL_ATTR vportAttrs[ARRAY_SIZE(ovsVportPolicy)];
+
+ASSERT(usrParamsCtx-inputBuffer != NULL);
+
+if (!NlAttrParse((PNL_MSG_HDR)msgIn,
+NLMSG_HDRLEN + GENL_HDRLEN + OVS_HDRLEN,
+NlMsgAttrsLen((PNL_MSG_HDR)msgIn),
+ovsVportPolicy, vportAttrs, ARRAY_SIZE(vportAttrs))) {
+return STATUS_INVALID_PARAMETER;
+}
+
+if (msgOut == NULL || usrParamsCtx-outputLength sizeof *msgOut) {
+return STATUS_NDIS_INVALID_LENGTH;
+}
+
+OvsAcquireCtrlLock();
+if (!gOvsSwitchContext) {
+OvsReleaseCtrlLock();
+return STATUS_INVALID_PARAMETER;
+}
+OvsReleaseCtrlLock();
+
+NdisAcquireRWLockWrite(gOvsSwitchContext-dispatchLock, lockState, 0);
+if (vportAttrs[OVS_VPORT_ATTR_NAME] != NULL) {
+portName = NlAttrGet(vportAttrs[OVS_VPORT_ATTR_NAME]);
+portNameLen = NlAttrGetSize(vportAttrs[OVS_VPORT_ATTR_NAME]);
+
+/* the port name is expected to be null-terminated */
+ASSERT(portName[portNameLen - 1] == '\0');
+
+vport = OvsFindVportByOvsName(gOvsSwitchContext, portName);
+}
+else if (vportAttrs[OVS_VPORT_ATTR_PORT_NO] != NULL) {
+vport = OvsFindVportByPortNo(gOvsSwitchContext,
+NlAttrGetU32(vportAttrs[OVS_VPORT_ATTR_PORT_NO]));
+}
+
+
Re: [ovs-dev] [PATCH 3/6] datapath-windows: remove vport from lists upon deletion
Acked-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com Tested-by: Alin Gabriel Serdean aserd...@cloudbasesolutions.com -Mesaj original- De la: dev [mailto:dev-boun...@openvswitch.org] În numele Nithin Raju Trimis: Monday, October 13, 2014 6:56 AM Către: dev@openvswitch.org Subiect: [ovs-dev] [PATCH 3/6] datapath-windows: remove vport from lists upon deletion In this patch, we fix a bug in the vport delete code. When a vport is deleted using a netlink command, we need to remove it from the 'ovsNamHashArray' and the 'portNoHashArray' as well. Addition of a vport adds the port to the lists. Signed-off-by: Nithin Raju nit...@vmware.com --- datapath-windows/ovsext/Datapath.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/datapath-windows/ovsext/Datapath.c b/datapath-windows/ovsext/Datapath.c index 19c0834..6c78ab8 100644 --- a/datapath-windows/ovsext/Datapath.c +++ b/datapath-windows/ovsext/Datapath.c @@ -1967,6 +1967,8 @@ OvsDeleteVportCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx, * Instead, we mark the datapath (ovs) part of the vport as * not created, i.e. we set vport-portNo = OVS_PORT_NUMBER_INVALID. */ +RemoveEntryList(vport-ovsNameLink); +RemoveEntryList(vport-portNoLink); vport-portNo = OVS_DPPORT_NUMBER_INVALID; vport-ovsName[0] = '\0'; } -- 1.7.4.1 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 1/1] netdev-dpdk: Move to DPDK 1.7.1
This patch updates the documentation to reflect that DPDK 1.7.1 is supported.
Travis scripts have also been updated to reflect this. DPDK phy and ring ports
were validated against DPDK 1.7.1.
(note: ring ports were validated with the upcoming multi-queue patch fix).
Reviewed-by: Mark D. Gray mark.d.g...@intel.com
Signed-off-by: Maryam Tahhan maryam.tah...@intel.com
---
.travis.yml | 2 +-
.travis/build.sh | 6 +++---
INSTALL.DPDK | 4 ++--
acinclude.m4 | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 4dfe15e..cd6e623 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -8,7 +8,7 @@ before_install: ./.travis/prepare.sh
env:
- OPTS=--disable-ssl
- TESTSUITE=1 KERNEL=1 OPTS=--with-linux=./linux-3.16.2
- - KERNEL=1 DPDK=1 OPTS=--with-dpdk=./dpdk-1.7.0/build
+ - KERNEL=1 DPDK=1 OPTS=--with-dpdk=./dpdk-1.7.1/build
script: ./.travis/build.sh $OPTS
diff --git a/.travis/build.sh b/.travis/build.sh
index 3872893..5dba4fe 100755
--- a/.travis/build.sh
+++ b/.travis/build.sh
@@ -19,9 +19,9 @@ function install_kernel()
function install_dpdk()
{
-wget http://www.dpdk.org/browse/dpdk/snapshot/dpdk-1.7.0.tar.gz
-tar xzvf dpdk-1.7.0.tar.gz /dev/null
-cd dpdk-1.7.0
+wget http://www.dpdk.org/browse/dpdk/snapshot/dpdk-1.7.1.tar.gz
+tar xzvf dpdk-1.7.1.tar.gz /dev/null
+cd dpdk-1.7.1
find ./ -type f | xargs sed -i
's/max-inline-insns-single=100/max-inline-insns-single=400/'
sed -ri 's,(CONFIG_RTE_BUILD_COMBINE_LIBS=).*,\1y,' config/common_linuxapp
make config CC=gcc T=x86_64-native-linuxapp-gcc
diff --git a/INSTALL.DPDK b/INSTALL.DPDK
index d9a77c9..7484b4b 100644
--- a/INSTALL.DPDK
+++ b/INSTALL.DPDK
@@ -14,10 +14,10 @@ and make.
Building and Installing:
-Required DPDK 1.7.
+Required DPDK 1.7.1
DPDK:
-Set dir i.g.: export DPDK_DIR=/usr/src/dpdk-1.7.0
+Set dir i.g.: export DPDK_DIR=/usr/src/dpdk-1.7.1
cd $DPDK_DIR
update config/common_linuxapp so that dpdk generate single lib file.
(modification also required for IVSHMEM build)
diff --git a/acinclude.m4 b/acinclude.m4
index 9a7f809..f9ee2ec 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -206,7 +206,7 @@ AC_DEFUN([OVS_CHECK_DPDK], [
OVS_LDFLAGS=$OVS_LDFLAGS -L$DPDK_LIB_DIR
OVS_CFLAGS=$OVS_CFLAGS -I$DPDK_INCLUDE
-# DPDK 1.7.0 pmd drivers are not linked unless --whole-archive is used.
+# DPDK 1.7.1 pmd drivers are not linked unless --whole-archive is used.
#
# This happens because the rest of the DPDK code doesn't use any symbol in
# the pmd driver objects, and the drivers register themselves using an
--
1.9.0
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Open Vswitch Feature Enhancement- Provider Bridging Feature
On Mon, Oct 13, 2014 at 02:22:00PM +0530, Hiteshi Madan wrote: We are thinking to contibute in following feature ; -IEEE 802.1ah (Provider Backbone Bridging). If anybody is already working on it please let us know. A patch has already been posted: http://openvswitch.org/pipermail/dev/2014-October/047132.html ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Bug#764847: openvswitch-switch: tuntap issues (commands)
On Sat, Oct 11, 2014 at 11:24:19AM -0400, westlake wrote: Package: openvswitch-switch Version: 2.3.0+git20140819-2 Severity: important (I gave a previous message containing a link to the thread http://openvswitch.org/pipermail/discuss/2011-October/005914.html , but over here in Debian, the device creates half-way) ovs-vsctl add-port bridge name tap dev -- set Interface tap dev type=tap ifconfig -a , would show it is created and in the down state applying, ip link set tap device up, ten starting a kvm reveals.. dev/net/tun (tap device): Device or resource busy So the tap device gets created half-way.. You filed this as a second bug report. Was this meant as additional information for your first bug report (#764843)? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Bug#764843: openvswitch-switch: tuntap creation failure
On Sat, Oct 11, 2014 at 11:12:32AM -0400, westlake wrote: Package: openvswitch Version: 2.3.0+git20140819-2 Severity: important http://openvswitch.org/pipermail/discuss/2011-October/005922.html An old bug is lingering somewhere in this latest edition.. Either it is recursive or something else is causing it. Can you provide an actual bug report? So far, all I have is that you think there's a bug related to tap devices, and a link to a report from 2011 about tap devices. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] datapath: compat: Fix compilation 3.11
Thanks for explaining. I don't think we necessarily need to tie the use of ip_tunnel kernel API to the existence on vxlan kernel API. On the other hand. It is not a big deal. Acked-by: Andy Zhou az...@nicira.com On Fri, Oct 10, 2014 at 7:38 PM, Pravin Shelar pshe...@nicira.com wrote: On Fri, Oct 10, 2014 at 5:47 PM, Andy Zhou az...@nicira.com wrote: O.K. Coming back to this patch. Would you please explain why this patch needs to affect how GRE, or iptunnel API is used? OVS has compat code for GRE, VXLAN and ip-tunnel APIs. this is controlled by GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS. But vxlan availability is not checked for defining GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS. 3.11 has GRE API but no vxlan API, that cause compilation error. This patch add check for vxlan and rename this symbol to USE_KERNEL_TUNNEL_API. On Fri, Oct 10, 2014 at 4:18 PM, Pravin Shelar pshe...@nicira.com wrote: On Fri, Oct 10, 2014 at 3:29 PM, Andy Zhou az...@nicira.com wrote: Would it be better to use kernel's CONFIG_VXLAN setting to determine if vxlan compat code should be used? tunnel compat code do not check for CONFIG option. User is expected to have these module options turned on to use OVS tunneling to get optimal performance. On Fri, Oct 10, 2014 at 8:21 AM, Pravin B Shelar pshe...@nicira.com wrote: Kernel 3.11 is only kernel where GRE APIs are available but not vxlan. Add check for vxlan xmit to detect this case. Reported-by: Dave Benson dben...@verdantnetworks.com Signed-off-by: Pravin B Shelar pshe...@nicira.com --- acinclude.m4 |1 + datapath/linux/compat/gre.c|2 +- datapath/linux/compat/include/net/gre.h|2 +- datapath/linux/compat/include/net/ip_tunnels.h |7 --- datapath/linux/compat/include/net/vxlan.h |2 +- datapath/linux/compat/ip_tunnels_core.c|2 +- datapath/linux/compat/vxlan.c |2 +- datapath/vport-geneve.c|1 - 8 files changed, 10 insertions(+), 9 deletions(-) diff --git a/acinclude.m4 b/acinclude.m4 index 9a7f809..9a7ea84 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -379,6 +379,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [ OVS_GREP_IFELSE([$KSRC/include/linux/openvswitch.h], [openvswitch_handle_frame_hook], [OVS_DEFINE([HAVE_RHEL_OVS_HOOK])]) + OVS_GREP_IFELSE([$KSRC/include/net/vxlan.h], [vxlan_xmit_skb]) OVS_GREP_IFELSE([$KSRC/include/net/vxlan.h], [bool xnet], [OVS_DEFINE([HAVE_VXLAN_XMIT_SKB_XNET_ARG])]) OVS_GREP_IFELSE([$KSRC/include/net/udp.h], [udp_flow_src_port], diff --git a/datapath/linux/compat/gre.c b/datapath/linux/compat/gre.c index de3d6eb..c7f2551 100644 --- a/datapath/linux/compat/gre.c +++ b/datapath/linux/compat/gre.c @@ -268,7 +268,7 @@ int gre_cisco_unregister(struct gre_cisco_protocol *proto) #endif /* !HAVE_GRE_CISCO_REGISTER */ -#ifndef GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS +#ifndef USE_KERNEL_TUNNEL_API /* GRE TX side. */ static void gre_csum_fix(struct sk_buff *skb) diff --git a/datapath/linux/compat/include/net/gre.h b/datapath/linux/compat/include/net/gre.h index f091b32..b4bf2f1 100644 --- a/datapath/linux/compat/include/net/gre.h +++ b/datapath/linux/compat/include/net/gre.h @@ -81,7 +81,7 @@ static inline __be16 tnl_flags_to_gre_flags(__be16 tflags) #endif /* LINUX_VERSION_CODE KERNEL_VERSION(3,10,0) */ #endif /* HAVE_GRE_CISCO_REGISTER */ -#ifndef GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS +#ifndef USE_KERNEL_TUNNEL_API #define gre_build_header rpl_gre_build_header void gre_build_header(struct sk_buff *skb, const struct tnl_ptk_info *tpi, diff --git a/datapath/linux/compat/include/net/ip_tunnels.h b/datapath/linux/compat/include/net/ip_tunnels.h index 9afab8c..d03be75 100644 --- a/datapath/linux/compat/include/net/ip_tunnels.h +++ b/datapath/linux/compat/include/net/ip_tunnels.h @@ -3,14 +3,15 @@ #include linux/version.h #if defined(HAVE_GRE_HANDLE_OFFLOADS) \ - LINUX_VERSION_CODE = KERNEL_VERSION(3,10,0) + LINUX_VERSION_CODE = KERNEL_VERSION(3,10,0) \ + defined(HAVE_VXLAN_XMIT_SKB) /* RHEL6 and RHEL7 both has backported tunnel API but RHEL6 has * older version, so avoid using RHEL6 backports. */ -#define GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS +#define USE_KERNEL_TUNNEL_API #endif -#ifdef GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS +#ifdef USE_KERNEL_TUNNEL_API #include_next net/ip_tunnels.h #if LINUX_VERSION_CODE KERNEL_VERSION(3,15,0) diff --git a/datapath/linux/compat/include/net/vxlan.h b/datapath/linux/compat/include/net/vxlan.h index 1b801dd..099d824 100644 --- a/datapath/linux/compat/include/net/vxlan.h +++ b/datapath/linux/compat/include/net/vxlan.h @@ -7,7 +7,7 @@ #include net/gre.h #include linux/version.h -#ifdef GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS +#ifdef USE_KERNEL_TUNNEL_API #include_next net/vxlan.h static inline int
Re: [ovs-dev] [PATCH] datapath: compat: Fix compilation 3.11
On Mon, Oct 13, 2014 at 9:22 AM, Andy Zhou az...@nicira.com wrote: Thanks for explaining. I don't think we necessarily need to tie the use of ip_tunnel kernel API to the existence on vxlan kernel API. On the other hand. It is not a big deal. We can do that later, as part of larger cleanup. Acked-by: Andy Zhou az...@nicira.com I pushed it to master and branch-2.3. Thanks. On Fri, Oct 10, 2014 at 7:38 PM, Pravin Shelar pshe...@nicira.com wrote: On Fri, Oct 10, 2014 at 5:47 PM, Andy Zhou az...@nicira.com wrote: O.K. Coming back to this patch. Would you please explain why this patch needs to affect how GRE, or iptunnel API is used? OVS has compat code for GRE, VXLAN and ip-tunnel APIs. this is controlled by GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS. But vxlan availability is not checked for defining GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS. 3.11 has GRE API but no vxlan API, that cause compilation error. This patch add check for vxlan and rename this symbol to USE_KERNEL_TUNNEL_API. On Fri, Oct 10, 2014 at 4:18 PM, Pravin Shelar pshe...@nicira.com wrote: On Fri, Oct 10, 2014 at 3:29 PM, Andy Zhou az...@nicira.com wrote: Would it be better to use kernel's CONFIG_VXLAN setting to determine if vxlan compat code should be used? tunnel compat code do not check for CONFIG option. User is expected to have these module options turned on to use OVS tunneling to get optimal performance. On Fri, Oct 10, 2014 at 8:21 AM, Pravin B Shelar pshe...@nicira.com wrote: Kernel 3.11 is only kernel where GRE APIs are available but not vxlan. Add check for vxlan xmit to detect this case. Reported-by: Dave Benson dben...@verdantnetworks.com Signed-off-by: Pravin B Shelar pshe...@nicira.com --- acinclude.m4 |1 + datapath/linux/compat/gre.c|2 +- datapath/linux/compat/include/net/gre.h|2 +- datapath/linux/compat/include/net/ip_tunnels.h |7 --- datapath/linux/compat/include/net/vxlan.h |2 +- datapath/linux/compat/ip_tunnels_core.c|2 +- datapath/linux/compat/vxlan.c |2 +- datapath/vport-geneve.c|1 - 8 files changed, 10 insertions(+), 9 deletions(-) diff --git a/acinclude.m4 b/acinclude.m4 index 9a7f809..9a7ea84 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -379,6 +379,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [ OVS_GREP_IFELSE([$KSRC/include/linux/openvswitch.h], [openvswitch_handle_frame_hook], [OVS_DEFINE([HAVE_RHEL_OVS_HOOK])]) + OVS_GREP_IFELSE([$KSRC/include/net/vxlan.h], [vxlan_xmit_skb]) OVS_GREP_IFELSE([$KSRC/include/net/vxlan.h], [bool xnet], [OVS_DEFINE([HAVE_VXLAN_XMIT_SKB_XNET_ARG])]) OVS_GREP_IFELSE([$KSRC/include/net/udp.h], [udp_flow_src_port], diff --git a/datapath/linux/compat/gre.c b/datapath/linux/compat/gre.c index de3d6eb..c7f2551 100644 --- a/datapath/linux/compat/gre.c +++ b/datapath/linux/compat/gre.c @@ -268,7 +268,7 @@ int gre_cisco_unregister(struct gre_cisco_protocol *proto) #endif /* !HAVE_GRE_CISCO_REGISTER */ -#ifndef GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS +#ifndef USE_KERNEL_TUNNEL_API /* GRE TX side. */ static void gre_csum_fix(struct sk_buff *skb) diff --git a/datapath/linux/compat/include/net/gre.h b/datapath/linux/compat/include/net/gre.h index f091b32..b4bf2f1 100644 --- a/datapath/linux/compat/include/net/gre.h +++ b/datapath/linux/compat/include/net/gre.h @@ -81,7 +81,7 @@ static inline __be16 tnl_flags_to_gre_flags(__be16 tflags) #endif /* LINUX_VERSION_CODE KERNEL_VERSION(3,10,0) */ #endif /* HAVE_GRE_CISCO_REGISTER */ -#ifndef GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS +#ifndef USE_KERNEL_TUNNEL_API #define gre_build_header rpl_gre_build_header void gre_build_header(struct sk_buff *skb, const struct tnl_ptk_info *tpi, diff --git a/datapath/linux/compat/include/net/ip_tunnels.h b/datapath/linux/compat/include/net/ip_tunnels.h index 9afab8c..d03be75 100644 --- a/datapath/linux/compat/include/net/ip_tunnels.h +++ b/datapath/linux/compat/include/net/ip_tunnels.h @@ -3,14 +3,15 @@ #include linux/version.h #if defined(HAVE_GRE_HANDLE_OFFLOADS) \ - LINUX_VERSION_CODE = KERNEL_VERSION(3,10,0) + LINUX_VERSION_CODE = KERNEL_VERSION(3,10,0) \ + defined(HAVE_VXLAN_XMIT_SKB) /* RHEL6 and RHEL7 both has backported tunnel API but RHEL6 has * older version, so avoid using RHEL6 backports. */ -#define GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS +#define USE_KERNEL_TUNNEL_API #endif -#ifdef GRE_USE_KERNEL_GRE_HANDLE_OFFLOADS +#ifdef USE_KERNEL_TUNNEL_API #include_next net/ip_tunnels.h #if LINUX_VERSION_CODE KERNEL_VERSION(3,15,0) diff --git a/datapath/linux/compat/include/net/vxlan.h b/datapath/linux/compat/include/net/vxlan.h index 1b801dd..099d824 100644 --- a/datapath/linux/compat/include/net/vxlan.h +++ b/datapath/linux/compat/include/net/vxlan.h @@ -7,7 +7,7 @@
Re: [ovs-dev] [PATCH 0/2] V4 Add 802.1ad (qinq) Support to OVS
Hey Tom, Let us know what you hear back on this stuff. Thanks On Sat, Oct 11, 2014 at 6:56 PM, Thomas F Herbert thomasfherb...@entpnt.com wrote: This patch adds 802.1ad support to OVS. It includes the user space and linux kernel portions. This effort is supported by Entry Point LLC. It has been tested in VMs and real-world environment at ATC Communications Inc. We would be interested in results from any other testers. Thomas F Herbert (2): V4 linux datapath Adds 802.1ad (qinq) support V4 user space Adds 802.1ad (qinq) support. datapath/actions.c| 27 +++-- datapath/flow.c | 80 ++--- datapath/flow.h | 1 + datapath/flow_netlink.c | 37 +- datapath/linux/compat/include/linux/openvswitch.h | 17 +-- lib/flow.c| 31 +- lib/flow.h| 12 +- lib/match.c | 2 +- lib/nx-match.c| 2 +- lib/odp-execute.c | 3 +- lib/odp-util.c| 130 ++ lib/odp-util.h| 2 +- lib/ofp-actions.c | 32 +++--- lib/ofp-actions.h | 13 ++- lib/ofp-util.c| 2 +- lib/packets.c | 2 +- lib/packets.h | 7 ++ ofproto/ofproto-dpif-xlate.c | 13 ++- utilities/ovs-ofctl.8.in | 3 +- 19 files changed, 326 insertions(+), 90 deletions(-) -- 1.8.3.2 -- Jeff Peterson | Chief Technology OfficerEntry Point, LLC ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/2] V4 Add 802.1ad (qinq) Support to OVS
Normally any reviews or feedback will be posted publicly anyhow. On Mon, Oct 13, 2014 at 11:22 AM, Jeff Peterson jpeter...@entpnt.com wrote: Hey Tom, Let us know what you hear back on this stuff. Thanks On Sat, Oct 11, 2014 at 6:56 PM, Thomas F Herbert thomasfherb...@entpnt.com wrote: This patch adds 802.1ad support to OVS. It includes the user space and linux kernel portions. This effort is supported by Entry Point LLC. It has been tested in VMs and real-world environment at ATC Communications Inc. We would be interested in results from any other testers. Thomas F Herbert (2): V4 linux datapath Adds 802.1ad (qinq) support V4 user space Adds 802.1ad (qinq) support. datapath/actions.c| 27 +++-- datapath/flow.c | 80 ++--- datapath/flow.h | 1 + datapath/flow_netlink.c | 37 +- datapath/linux/compat/include/linux/openvswitch.h | 17 +-- lib/flow.c| 31 +- lib/flow.h| 12 +- lib/match.c | 2 +- lib/nx-match.c| 2 +- lib/odp-execute.c | 3 +- lib/odp-util.c| 130 ++ lib/odp-util.h| 2 +- lib/ofp-actions.c | 32 +++--- lib/ofp-actions.h | 13 ++- lib/ofp-util.c| 2 +- lib/packets.c | 2 +- lib/packets.h | 7 ++ ofproto/ofproto-dpif-xlate.c | 13 ++- utilities/ovs-ofctl.8.in | 3 +- 19 files changed, 326 insertions(+), 90 deletions(-) -- 1.8.3.2 -- Jeff Peterson | Chief Technology OfficerEntry Point, LLC ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev -- I don't normally do acked-by's. I think it's my way of avoiding getting blamed when it all blows up. Andrew Morton ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Bug#763428: Bug#763428: openvswitch-switch: openvswitch doesn't work anymore since kernel 3.16 update
On Mon, Oct 13, 2014 at 10:47:19AM +0200, Laurent GUERBY wrote: On Wed, 8 Oct 2014 13:02:42 -0700 Ben Pfaff b...@nicira.com wrote: I can't reproduce this problem with OVS master and upstream kernel 3.16, or with OVS branch-2.3 on the commit from which the Debian packages were made. Now I'm downloading a Debian ISO so that I can try it with the exact kernel and OVS packaging against which the bug was reported. Did you manage to reproduce the bug with debian ISO? OVS also works OK for me with linux-image-3.16-2-686-pae version 3.16.3-2 and openvswitch-switch 2.3.0+git20140819-2. The configuration I tested was very simple: remove IP address from eth0, create bridge br0 and add eth0 to the bridge, then run dhclient on br0 and verify connectivity. I then verified with ovs-dpctl show and ovs-dpctl dump-flows that traffic was passing through Open vSwitch. With a simple setup like that, does OVS work for you? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2] lib/netlink-socket.c: always pass the output buffer in a transaction
On Oct 7, 2014, at 8:01 PM, Eitan Eliahu elia...@vmware.com wrote: Hi Nithin, Thanks for addressing the transactional error issue. Are we sure we want to make another copy for the Reply just for getting the transactional error on a different buffer? Can we use the stack buffer only if the caller does not provide enough space for the transactional error message? Please find a comment inline. Eitan hi Eitan, Like we discussed offline, we can optimize the code to avoid copies by using the equivalent of iovs in the future. For now, it is best to provide kernel with a buffer where it can write the output. Thanks, -- Nithin ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2] lib/netlink-socket.c: always pass the output buffer in a transaction
On Tue, Oct 07, 2014 at 03:08:53PM -0700, Nithin Raju wrote: We need to pass down the output buffer so that the kernel can return transaction status - error or otherwise. Also, we were processing the output buffer only when when 'txn-reply != NULL' ie when the caller specified an ofpbuf for the reply. In this patch, the code has been updated to process the reply unconditionally, but making sure to copy the reply to the 'txn-reply' only when it is not NULL. The reason for the unconditional processing is we can pass up transactional errors in 'txn-error'. Otherwise, it results in an endless loop of calling nl_transact(). Signed-off-by: Nithin Raju nit...@vmware.com Applied, thanks! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH/RFC repost 7/8] ofproto: translate datapath select group action
On Thu, Oct 09, 2014 at 10:14:36AM +0900, Simon Horman wrote: On Fri, Sep 26, 2014 at 04:57:25PM -0700, Ben Pfaff wrote: On Thu, Sep 18, 2014 at 10:55:10AM +0900, Simon Horman wrote: This patch is a prototype and has several limitations: * It assumes that no actions follow a select group action because the resulting packet after a select group action may differ depending on the bucket used. It may be possible to address this problem using recirculation. Or to not use the datapath select group in such situations. In any case this patch does not solve this problem or even prevent it from occurring. It seems like this limitation in particular is a pretty big one. Do you have a good plan in mind for how to resolve it? Hi Ben, it seems to me that this would be somewhat difficult to resolve in the datapath so I propose not doing so. And I have two ideas on how to resolve this problem outside of the datapath. 1. Recirculation It seems to me that it ought to be possible to handle this by recirculating if actions occur after an ODP select group action. This could be made slightly more selective by only recirculating if the execution different buckets may result in different packet contents and the actions after the ODP select group action rely on the packet contents (e.g. set actions do but output actions do not). My feeling is that this could be implemented by adding a small amount of extra state to action translation in ovs-vswitchd. 2. Fall back to selecting buckets in ovs-vswtichd The idea here is to detect cases where there would be a problem executing actions after an ODP select group action and in that case to select buckets in ovs-vswtichd: that is use the existing bucket translation code in ovs-vswtichd. Though this seems conceptually simpler than recirculation it seems to me that it would be somewhat more difficult to implement as it implies a two stage translation process: e.g. one stage to determine if an ODP select group may be used; and one to perform the translation. I seem to recall trying various two stage translation processes as part some earlier unrelated work. And my recollection is that the result of my previous efforts were not pretty. Both of the above more or less negate any benefits of ODP select group action. In particular lowering flow setup cost and potentially allowing complete offload of select groups from the datapath to hardware. However I think that this case is not a common one as it requires both of the following. And I think they are both not usual use cases. * Different buckets modifying packets in different ways - My expectation is that it is common for buckets to be homogeneous in regards to packet modifications. But perhaps this is na??ve in the context of VLANs, MPLS, and similar tags that can be pushed and popped. * Actions that rely on packet contents after - My expectation is that it is common to use a select group to output packets and that is the final action performed. I am glad that you have thought about it. Your ideas seem like a good start to me. Personally, approach #2, of falling back to selecting buckets in ovs-vswitchd, seems like a clean solution to me, although if it really takes multiple stages in translation then that is undesirable, so I hope that some clean and simple approach works out. I think that we probably need a solution before we can apply the patch series, because otherwise we end up with half-working code. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/2] Refinements on userspace tunneling pathces.
On Fri, Oct 10, 2014 at 3:48 PM, Jarno Rajahalme jrajaha...@nicira.com wrote: I wanted to see that the recent classifier improvement was enough to remove the need to add locking when an classifier instance is used as a container. To that end I improved the relevant code in Pravin's userspace tunneling patch. These can only be applied after that patch, or preferably Pravin will merge these in. Looks good to me. I folded in both patches in the tunneling patch. Thanks. Jarno Rajahalme (2): lib/tnl-router: Support overlapping routes, LPM lib/tnp-ports: Use classifier more efficiently. lib/tnl-ports.c | 102 +++-- lib/tnl-router.c | 217 +- 2 files changed, 174 insertions(+), 145 deletions(-) -- 1.7.10.4 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] lib/classifier: Minimize critical section.
On Fri, Oct 10, 2014 at 04:18:45PM -0700, Jarno Rajahalme wrote: classifier_find_rule_exactly() only needs the mutex to protect the list traversal. Subtables are already RCU protected. Locking here can be eliminated completely when RCU list is available. Signed-off-by: Jarno Rajahalme jrajaha...@nicira.com Acked-by: Ben Pfaff b...@nicira.com ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status of patch adding Auto Attach feature
Hi, A while back (Oct. 2) we posted a series of patches offering support for the Auto Attach feature. A description of this feature can be found here. http://openvswitch.org/pipermail/dev/2014-October/046651.html I'm curious to know if anyone has had a chance to look at this. Thanks, Dennis Flynn Avaya, Inc. Ludovic Beliveau WindRiver, Inc. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/6] datapath-windows: vport add/delete commands with fixes
On Sun, Oct 12, 2014 at 08:56:13PM -0700, Nithin Raju wrote: In the first two patches of the series, I have rebased Samuel's patches that were submitted for review to tip-of-master. Only Samuel is listed as the Author just like in the original patch. In subsequent patches, we make fixes to the code to make it work. One of them is not related to the vport add commands, but was nevertheless required to stabilize the code. I applied all of these, thank you! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Status of patch adding Auto Attach feature
On Mon, Oct 13, 2014 at 09:00:54PM +, Flynn, Dennis R (Dennis) wrote: A while back (Oct. 2) we posted a series of patches offering support for the Auto Attach feature. A description of this feature can be found here. http://openvswitch.org/pipermail/dev/2014-October/046651.html I'm curious to know if anyone has had a chance to look at this. I keep meaning to review it. It's big, which means that I need a good block of time to properly take a look. Fortunately, I've got some time this afternoon, so I'm going to look it over now. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2 6/6] datapath-windows: Assert fix in Netlink.c
On Sat, Oct 11, 2014 at 03:07:41PM -0700, Ankur Sharma wrote: NlBufAt should be called with valid boundary limits (within head and tail). Incorrect argument to NlBufAt was leading to assert hit, fixed the same. Signed-off-by: Ankur Sharma ankursha...@vmware.com Acked-by: Nithin Raju nit...@vmware.com Tested-by: Nithin Raju nit...@vmware.com I applied this series, thank you! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH RFC 2/2] openvswitch: Userspace tunneling.
On Thu, Oct 9, 2014 at 2:53 PM, Jarno Rajahalme jrajaha...@nicira.com wrote: Pravin, Please find my comments below. I did not snip any code to make it easier for you to keep into context while reading this review. Thanks for detailed review. Jarno On Oct 3, 2014, at 8:24 PM, Pravin B Shelar pshe...@nicira.com wrote: Following patch adds support for userspace tunneling. Tunneling needs three more component first is routing table which is configured by user and second is ARP cache which build automatically by snooping arp. And third is tunnel protocol table which list all listening protocols which is populated by vswitchd as tunnel ports are added. Tunneling works as follows: On packet receive vswitchd check if this packet is targeted to tunnel port. If it is then vswitchd inserts tunnel pop action which pops header and sends packet to tunnel port. On packet xmit rather than generating Set tunnel action it generate tunnel push action which has tunnel header data. datapath can use tunnel-push action data to generate header for each packet and forward this packet to output port. Since tunnel-push action contains most of packet header it need to lookup routing table and arp table to build this action. Signed-off-by: Pravin B Shelar pshe...@nicira.com --- Makefile.am | 1 + README-Userspace-Tunneling| 81 datapath/linux/compat/include/linux/openvswitch.h | 10 + debian/openvswitch-common.docs| 1 + lib/automake.mk | 9 +- lib/dpif-netdev.c | 125 +++- lib/dpif.c| 25 +++ lib/dpif.h| 4 + lib/netdev-bsd.c | 3 + lib/netdev-dpdk.c | 3 + lib/netdev-dummy.c| 3 + lib/netdev-linux.c| 3 + lib/netdev-provider.h | 9 + lib/netdev-vport.c| 186 +++-- lib/netdev.c | 34 lib/netdev.h | 7 + lib/odp-execute.c | 2 + lib/odp-util.c| 118 +++ lib/odp-util.h| 4 + lib/ofpbuf.h | 8 + lib/packets.c | 35 lib/packets.h | 9 +- lib/tnl-arp-cache.c | 214 +++ lib/tnl-arp-cache.h | 47 + lib/tnl-ports.c | 203 ++ lib/tnl-ports.h | 49 + lib/tnl-router.c | 237 ++ lib/tnl-router.h | 42 lib/vlog.c| 1 + lib/vxlan.h | 46 + ofproto/ofproto-dpif-xlate.c | 176 +++- ofproto/ofproto-dpif-xlate.h | 3 +- ofproto/ofproto-dpif.c| 38 +++- ofproto/tunnel.c | 79 +++- ofproto/tunnel.h | 10 +- rhel/openvswitch.spec.in | 2 +- vswitchd/ovs-vswitchd.8.in| 4 + vswitchd/ovs-vswitchd.c | 6 + 38 files changed, 1785 insertions(+), 52 deletions(-) create mode 100644 README-Userspace-Tunneling create mode 100644 lib/tnl-arp-cache.c create mode 100644 lib/tnl-arp-cache.h create mode 100644 lib/tnl-ports.c create mode 100644 lib/tnl-ports.h create mode 100644 lib/tnl-router.c create mode 100644 lib/tnl-router.h create mode 100644 lib/vxlan.h diff --git a/Makefile.am b/Makefile.am index 77ceec6..3941e0f 100644 --- a/Makefile.am +++ b/Makefile.am @@ -84,6 +84,7 @@ EXTRA_DIST = \ PORTING \ README.md \ README-lisp \ + README-Userspace-Tunneling \ REPORTING-BUGS \ TODO \ .travis.yml \ diff --git a/README-Userspace-Tunneling b/README-Userspace-Tunneling new file mode 100644 index 000..1aebbca --- /dev/null +++ b/README-Userspace-Tunneling @@ -0,0 +1,81 @@ + +Open vSwitch support tunneling in userspace. Tunneling is implemented in +platform independent way. But it does expect following from platform: +1. dpif-netdev bridge is backed by netdev should be able to + reply to ARP requests. What does it mean for a netdev to be able to reply to ARP requests? Or do you mean that the bridge should be able to reply to ARP requests? yes, bridge is suppose to reply to ARP, but bridge is backed by a netdev
Re: [ovs-dev] [PATCH 0/3] auto-attach: Add support for IETF Auto Attach standard
On Thu, Oct 02, 2014 at 06:42:10PM -0400, Ludovic Beliveau wrote: This patch sequence provides OVS support for the IETF Auto-Attach SPBM draft standard. This standard describes a compact method of using IEEE 802.1AB Link Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest Path Bridging (SPB) network to automatically attach network devices to individual services in a SPB network. The intent here is to allow network applications and devices using OVS to be able to easily take advantage of features offered by industry standard SPB networks. Details of the Auto-Attach standard can be found here. http://tools.ietf.org/html/draft-unbehagen-lldp-spb-00 We have modified the OVS source code to integrate basic LLDP protocol support as required to implement Auto-Attach (AA). We modeled our LLDP code changes after other protocols currently supported by OVS (BFD, CFM, etc.). We have chosen to base this OVS LLDP work on the open source LLDPD project headed by Vincent Bernat. Details of the LLDPD project can be found here. Is the goal to make OVS into an auto-attach client or server or both? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 1/3] auto-attach: Initial support for Auto-Attach standard
On Thu, Oct 02, 2014 at 06:42:24PM -0400, Ludovic Beliveau wrote: This commit provides the initial delivery of support for the Auto-Attach standard to Open vSwitch. This standard describes a compact method of using IEEE 802.1AB Link Layer Discovery Protocol (LLDP) with a IEEE 802.1aq Shortest Path Bridging (SPB) network to automatically attach network devices not supporting IEEE 802.1ah to individual services in a SPB network. Specifically this commit adds base LLDP support to OVS along with the LLDP extension required to support Auto-Attach. The base LLDP code within this commit is adapted from the open source LLDPD project headed by Vincent Bernat. This base code is augmented with OVS specific logic which integrates LLDP into OVS and which extends LLDP to support Auto-Attach. The required build system changes are included to configure and build OVS with this new feature. This is the first of a series of commits. Subsequent commits will be provided to complete the task of adding Auto-Attach to OVS. Signed-off-by: Ludovic Beliveau ludovic.beliv...@windriver.com Signed-off-by: Dennis Flynn drfl...@avaya.com Thanks for the patch! I have some comments. GCC reports: ../lib/lldp.c: In function 'lldp_send': ../lib/lldp.c:515:9: error: assignment from incompatible pointer type [-Werror] ../lib/lldp.c: In function 'lldp_decode': ../lib/lldp.c:1192:25: error: assignment from incompatible pointer type [-Werror] ../lib/lldp.c:1192:25: error: assignment from incompatible pointer type [-Werror] ../lib/lldp.c:1192:25: error: assignment from incompatible pointer type [-Werror] ../lib/ovs-lldp.c: In function 'aa_print_isid_status': ../lib/ovs-lldp.c:317:17: error: assignment from incompatible pointer type [-Werror] cc1: all warnings being treated as errors ../lib/ovs-lldp.c: In function 'update_mapping_on_lldp': ../lib/ovs-lldp.c:433:5: error: assignment from incompatible pointer type [-Werror] ../lib/ovs-lldp.c:433:5: error: assignment from incompatible pointer type [-Werror] ../lib/ovs-lldp.c:433:5: error: assignment from incompatible pointer type [-Werror] ../lib/ovs-lldp.c: In function 'aa_mapping_unregister': ../lib/ovs-lldp.c:659:17: error: assignment from incompatible pointer type [-Werror] ../lib/ovs-lldp.c:669:25: error: assignment from incompatible pointer type [-Werror] sparse reports: ../lib/lldp-frame.c:65:17: warning: incorrect type in argument 1 (different base types) ../lib/lldp-frame.c:65:17:expected restricted ovs_be16 [usertype] x ../lib/lldp-frame.c:65:17:got unsigned int [unsigned] [assigned] sum ../lib/lldpd.c:517:36: warning: restricted ovs_be16 degrades to integer ../lib/lldpd.c:525:5: warning: incorrect type in argument 1 (different base types) ../lib/lldpd.c:525:5:expected restricted ovs_be16 [usertype] x ../lib/lldpd.c:525:5:got unsigned short [unsigned] [addressable] [usertype] ether_type There's a significant amount of duplication here between data structures already implemented in OVS and data structures implemented in this patch. Open vSwitch already has a doubly linked list type, for example, but this patch imports and uses the linked list types and macros from BSD. I'd prefer to avoid this kind of duplication. Usually, bit-fields are not a portable way to represent wire formats, at least without compile-time conditionals for endianness, because different compilers and architectures lay them out differently. I see some use of bit-fields in this patch, e.g. in aa-structs.h, without tests for endianness. Do these structures represent protocol wire formats? I see that support for auto-attach can be enabled and disabled at configuration time. This is unusual for an OVS feature: usually, we build in support for every feature. This makes testing and maintenance easier because it reduces the number of configurations that must be built and tested. It also reduces the number of #ifdefs in the source code (I see many #ifdefs for auto-attach). Is there some reason that auto-attach cannot be built unconditionally? Actually, I wonder whether this has been tested when configuring without --enable-auto-attach. This code in lib/marshal.h indicates that it would fail to build without --enable-auto-attach: #ifdef ENABLE_AUTO_ATTACH ignorem, // ignore has a direct naming conflict in ovs (and therefore has been renamed) #else ignore #endif This patch adds many files with various licenses and copyright holders, so it should update NOTICE at the top level and copyright.in in the debian directory with new details. On that same note, lldp-frame.h says: /* This set of macro are used to build packets. The current position in buffer * is `pos'. The length of the remaining space in buffer is `length'. `type' * should be a member of `types'. This was stolen from ladvd which was adapted * from
Re: [ovs-dev] [PATCH 2/3] auto-attach: Add auto-attach support to ofproto layer
On Thu, Oct 02, 2014 at 06:42:33PM -0400, Ludovic Beliveau wrote: Signed-off-by: Ludovic Beliveau ludovic.beliv...@windriver.com Signed-off-by: Dennis Flynn drfl...@avaya.com This seems pretty reasonable except that I'd much prefer to delete all the #ifdefs. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 3/3] auto-attach: Add auto-attach support to bridge layer and command set
On Thu, Oct 02, 2014 at 06:42:55PM -0400, Ludovic Beliveau wrote: This is the final commit in the series of commits that deliver initial support for Auto-Attach. Specifically this commit delivers auto-attach support to the OVS bridge layer as well as the new auto-attach commands. The OVSDB schema is modified to define the new auto-attach entries. The man pages and unit tests are also updated. Signed-off-by: Ludovic Beliveau ludovic.beliv...@windriver.com Signed-off-by: Dennis Flynn drfl...@avaya.com Thanks for the patch! Some patch in the series should add a notes to NEWS, to let users know about the new feature. I don't understand the value of a command to delete the database, as this adds to ovs-ctl. (If it is valuable, it should be documented in the ovs-ctl manpage and usable via the various initscripts.) The ovs-vsctl program can talk to any Open vSwitch instance, not just to an instance on the machine where it runs, so even if it makes sense to make auto-attach a configuration time option for ovs-vswitchd, I don't think it makes sense to apply that same option to ovs-vsctl. It would be nice to say a few words in ovs-vsctl(8) and vswitch.xml about what auto-attach is, in what circumstances one would use it, and where one should go for more information. Regarding the database schema, it looks like AutoAttachMapping is used as a map from an integer to an integer. Do you expect to need to add more data than (isid,vlan) pairs in the future? If not, then it would be easier to make the mappings column just an integer-integer map rather than involving another table. It also seems odd that the isid and vlan values in AutoAttachMapping are optional; wouldn't one need to provide both in each case? Thanks, Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv7 07/11] hash: Add 128-bit murmurhash.
On Tue, Oct 07, 2014 at 12:23:34AM +1300, Joe Stringer wrote:
Add the 128-bit murmurhash by Austin Appleby, r150 from:
http://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Ben Pfaff b...@nicira.com
Compiling on i386, I get:
../lib/hash.c:77:1: error: static declaration of 'hash_bytes128' follows
non-static declaration
hash_bytes128(const void *p_, size_t len, uint32_t basis, ovs_u128 *out)
^
../lib/hash.h:36:6: note: previous declaration is here
void hash_bytes128(const void *_, size_t n_bytes, uint32_t basis,
^
1 error generated.
which is easily fixed with:
diff --git a/lib/hash.c b/lib/hash.c
index fe742cd..1042c97 100644
--- a/lib/hash.c
+++ b/lib/hash.c
@@ -73,7 +73,7 @@ hash_words64__(const uint64_t p[], size_t n_words,
uint64_t basis)
}
#if !(defined(__x86_64__))
-static void
+void
hash_bytes128(const void *p_, size_t len, uint32_t basis, ovs_u128 *out)
{
const uint32_t c1 = 0x239b961b;
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv7 10/11] dpif: Index flows using unique identifiers.
On Tue, Oct 07, 2014 at 12:23:37AM +1300, Joe Stringer wrote: This patch modifies the dpif interface to allow flows to be manipulated using a 128-bit identifier. This allows revalidator threads to perform datapath operations faster, as they do not need to serialise the entire flow key for operations like flow_get and flow_delete. In conjunction with a future patch to simplify the dump interface, this provides a significant performance benefit for revalidation. When handlers assemble flow_put operations, they specify a unique identifier (UID) for each flow as it is passed down to the datapath to be stored with the flow. The UID is currently provided to handlers by the dpif during upcall processing. When revalidators assemble flow_get or flow_del operations, they specify the UID for the flow along with the key, and a boolean for whether to send the request using only a UID or to send the request using the UID and flow key. The former is preferred for newer datapaths that support UID, while the latter is used for backwards compatibility. Signed-off-by: Joe Stringer joestrin...@nicira.com For whatever reason, the new struct odputil_uidbuf stuck out at me, so I spent a few minutes trying to figure out why it was needed. One use, as the new 'uid' member in struct ukey_op, doesn't appear to be used for anything. When the delete the member, the build still succeeds. The other use for this structure is in dpif-netlink.c. I find myself wondering whether it is valuable there either. It seems that in struct dpif_netlink_flow the main purpose of uid_buf is to make it possible to handle uids of types or sizes other than ovs_u128, but I am not sure that that is essential, especially since the dpif interface itself only supports ovs_u128. I think it might be more convenient to replace const struct nlattr *uid; /* OVS_FLOW_ATTR_UID. */ size_t uid_len; ... struct odputil_uidbuf uid_buf; /* Buffer to hold 'uid'. */ by something like: ovs_u128 uid; /* OVS_FLOW_ATTR_UID. */ bool uid_present; /* Is there a UID? */ The one case that this wouldn't handle neatly, I think, is the case where the kernel passes to userspace a UID of the wrong size, but I think for that we could just mark the uid as not present (and possibly log something). Actually odp_uid_from_nlattrs() looks pretty close to that anyhow. Acked-by: Ben Pfaff b...@nicira.com ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH RFC 2/2] openvswitch: Userspace tunneling.
On Oct 13, 2014, at 2:32 PM, Pravin Shelar pshe...@nicira.com wrote:
+case OVS_ACTION_ATTR_TUNNEL_PUSH:
+if (*depth MAX_RECIRC_DEPTH) {
+struct dpif_packet *tnl_pkt[NETDEV_MAX_RX_BATCH];
+int err;
+
+if (may_steal) {
+dp_netdev_clone_pkt_batch(tnl_pkt, packets, cnt);
+packets = tnl_pkt;
+}
Should this be the reverse? Clone if can NOT take the packets?
right,
+
+err = odp_push_tunnel_action(dp, a, packets, cnt);
+if (err) {
+dp_netdev_drop_packets(tnl_pkt, cnt, may_steal);
+break;
+}
+
+(*depth)++;
+dp_netdev_input(pmd, packets, cnt);
+(*depth)--;
+return;
+}
Should “break” here.
packets are already consumed so we can not break here.
Do you really intend to fall through to the TUNNEL_POP case?
Jarno
+
+case OVS_ACTION_ATTR_TUNNEL_POP:
+if (*depth = MAX_RECIRC_DEPTH) {
+break;
+}
+
+p =
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Bug#764847: openvswitch-switch: tuntap issues (commands)
(the earlier report can be deleted) Have you been able to confirm/replicate this bug? The url I've given exhibits a more broken case, but what I've encountered after checking the created tap device almost gets properly created. On 13/10/14 11:21 AM, Ben Pfaff wrote: On Sat, Oct 11, 2014 at 11:24:19AM -0400, westlake wrote: Package: openvswitch-switch Version: 2.3.0+git20140819-2 Severity: important (I gave a previous message containing a link to the thread http://openvswitch.org/pipermail/discuss/2011-October/005914.html , but over here in Debian, the device creates half-way) ovs-vsctl add-port bridge name tap dev -- set Interface tap dev type=tap ifconfig -a , would show it is created and in the down state applying, ip link set tap device up, ten starting a kvm reveals.. dev/net/tun (tap device): Device or resource busy So the tap device gets created half-way.. You filed this as a second bug report. Was this meant as additional information for your first bug report (#764843)? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2] lib/dpif-netdev: Integrate megaflow classifier.
Hey Jarno, I have some high-level comments/questions as follow: On Tue, Oct 7, 2014 at 2:43 PM, Jarno Rajahalme jrajaha...@nicira.com wrote: flow inserts and removals are simplified: - No need for classifier internal mutex, as dpif-netdev already has a 'flow_mutex'. I'm thinking maybe we should keep the per-classifier mutex and get rid of the 'flow_mutex' (make the code simpler). The reason we use flow_mutex on current master is that we need to include the lookup 'dp_netdev_lookup_flow()' into the critical section (e.g. in 'fast_path_processing()', since two or more pmd threads could be trying to install the same dp flow). If we change to per-pmd thread classifier/flow-table, then the situation like above will not happen. Instead, we are facing the issue of pmd thread trying to install and revalidator thread trying to delete at the same time. In that case, I think we just need classifier internal mutex to protect the access to cmap. However, there could be one exception, which is using ovs-appctl dpctl/* cmds to add/del flows (main thread and pmd thread could install the same flow at same time). We could workaround it by registering the flow operation and have pmd thread execute it. What do you think? There could be other cases I missed, that makes the flow_mutex required. ;D - Number of memory allocations/frees can be halved. Are you referring to getting rid of 'cls_match_alloc()' called in insert_rule() ? Lookup code path is a bit more effcient as well, as we can rely on netdev_flow_key always having inline data. will take a closer look of the code later. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] nicira-ext.h: Update comments
Signed-off-by: YAMAMOTO Takashi yamam...@valinux.co.jp --- include/openflow/nicira-ext.h | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/include/openflow/nicira-ext.h b/include/openflow/nicira-ext.h index 65ba950..b20bab3 100644 --- a/include/openflow/nicira-ext.h +++ b/include/openflow/nicira-ext.h @@ -287,6 +287,9 @@ OFP_ASSERT(sizeof(struct nx_async_config) == 24); * short, that is also supported by Open vSwitch. This section also defines a * replacement for each OpenFlow message that includes struct ofp10_match. * + * OpenFlow 1.2+ introduced OpenFlow Extensible Match (OXM), adapting + * the design of NXM. The format of NXM and OXM are compatible. + * * * Format * == @@ -307,10 +310,12 @@ OFP_ASSERT(sizeof(struct nx_async_config) == 24); * +--+---+--+--+ * * The most-significant 23 bits of the header are collectively nxm_type. - * Bits 16...31 are nxm_vendor, one of the NXM_VENDOR_* values below. Bits - * 9...15 are nxm_field, which is a vendor-specific value. nxm_type normally - * designates a protocol header, such as the Ethernet type, but it can also - * refer to packet metadata, such as the switch port on which a packet arrived. + * Bits 16...31 are nxm_vendor, one of OFPXMC12_* values. In case of + * NXM, it's either OFPXMC12_NXM_0 or OFPXMC12_NXM_1. + * Bits 9...15 are nxm_field, which is a vendor-specific value. nxm_type + * normally designates a protocol header, such as the Ethernet type, but it + * can also refer to packet metadata, such as the switch port on which a packet + * arrived. * * Bit 8 is nxm_hasmask (labeled hm above for space reasons). The meaning * of this bit is explained later. -- 1.9.4 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH/RFC repost 7/8] ofproto: translate datapath select group action
On Mon, Oct 13, 2014 at 01:46:24PM -0700, Ben Pfaff wrote: On Thu, Oct 09, 2014 at 10:14:36AM +0900, Simon Horman wrote: On Fri, Sep 26, 2014 at 04:57:25PM -0700, Ben Pfaff wrote: On Thu, Sep 18, 2014 at 10:55:10AM +0900, Simon Horman wrote: This patch is a prototype and has several limitations: * It assumes that no actions follow a select group action because the resulting packet after a select group action may differ depending on the bucket used. It may be possible to address this problem using recirculation. Or to not use the datapath select group in such situations. In any case this patch does not solve this problem or even prevent it from occurring. It seems like this limitation in particular is a pretty big one. Do you have a good plan in mind for how to resolve it? Hi Ben, it seems to me that this would be somewhat difficult to resolve in the datapath so I propose not doing so. And I have two ideas on how to resolve this problem outside of the datapath. 1. Recirculation It seems to me that it ought to be possible to handle this by recirculating if actions occur after an ODP select group action. This could be made slightly more selective by only recirculating if the execution different buckets may result in different packet contents and the actions after the ODP select group action rely on the packet contents (e.g. set actions do but output actions do not). My feeling is that this could be implemented by adding a small amount of extra state to action translation in ovs-vswitchd. 2. Fall back to selecting buckets in ovs-vswtichd The idea here is to detect cases where there would be a problem executing actions after an ODP select group action and in that case to select buckets in ovs-vswtichd: that is use the existing bucket translation code in ovs-vswtichd. Though this seems conceptually simpler than recirculation it seems to me that it would be somewhat more difficult to implement as it implies a two stage translation process: e.g. one stage to determine if an ODP select group may be used; and one to perform the translation. I seem to recall trying various two stage translation processes as part some earlier unrelated work. And my recollection is that the result of my previous efforts were not pretty. Both of the above more or less negate any benefits of ODP select group action. In particular lowering flow setup cost and potentially allowing complete offload of select groups from the datapath to hardware. However I think that this case is not a common one as it requires both of the following. And I think they are both not usual use cases. * Different buckets modifying packets in different ways - My expectation is that it is common for buckets to be homogeneous in regards to packet modifications. But perhaps this is na??ve in the context of VLANs, MPLS, and similar tags that can be pushed and popped. * Actions that rely on packet contents after - My expectation is that it is common to use a select group to output packets and that is the final action performed. I am glad that you have thought about it. Your ideas seem like a good start to me. Personally, approach #2, of falling back to selecting buckets in ovs-vswitchd, seems like a clean solution to me, although if it really takes multiple stages in translation then that is undesirable, so I hope that some clean and simple approach works out. Thanks. I'll focus on #2 and see how far I can get. I think that we probably need a solution before we can apply the patch series, because otherwise we end up with half-working code. Yes, I agree. It needs to be solved before it can be merged. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH v1 1/2] datapath-windows: Fix CtrlLock acquire issue in OvsReadEventCmdHandler
OvsReadEventCmdHandler was calling OvsRemoveEventEntry after acquiring
CtrlLock. OvsRemoveEventEntry in turn also tries to acquire the same lock.
Fixed the same.
Also, in Event.c we removed the APIs OvsAcquireEventQueueLock and
OvsReleaseEventQueueLock. These APIs were acquiring and releasing
CtrlLock only. Apis OvsAcquireCtrlLock and OvsReleaseCtrlLock
should be used for this purpose.
Signed-off-by: Ankur Sharma ankursha...@vmware.com
---
datapath-windows/ovsext/Datapath.c | 3 ++-
datapath-windows/ovsext/Event.c| 54 --
2 files changed, 25 insertions(+), 32 deletions(-)
diff --git a/datapath-windows/ovsext/Datapath.c
b/datapath-windows/ovsext/Datapath.c
index 6c78ab8..cb391a6 100644
--- a/datapath-windows/ovsext/Datapath.c
+++ b/datapath-windows/ovsext/Datapath.c
@@ -2133,9 +2133,11 @@ OvsReadEventCmdHandler(POVS_USER_PARAMS_CONTEXT
usrParamsCtx,
OvsAcquireCtrlLock();
if (!gOvsSwitchContext) {
+OvsReleaseCtrlLock();
status = STATUS_SUCCESS;
goto cleanup;
}
+OvsReleaseCtrlLock();
/* remove an event entry from the event queue */
status = OvsRemoveEventEntry(usrParamsCtx-ovsInstance, eventEntry);
@@ -2149,7 +2151,6 @@ OvsReadEventCmdHandler(POVS_USER_PARAMS_CONTEXT
usrParamsCtx,
}
cleanup:
-OvsReleaseCtrlLock();
return status;
}
#endif /* OVS_USE_NL_INTERFACE */
diff --git a/datapath-windows/ovsext/Event.c b/datapath-windows/ovsext/Event.c
index 467771d..0a45f24 100644
--- a/datapath-windows/ovsext/Event.c
+++ b/datapath-windows/ovsext/Event.c
@@ -47,18 +47,6 @@ OvsCleanupEventQueue()
ASSERT(ovsNumEventQueue == 0);
}
-static __inline VOID
-OvsAcquireEventQueueLock()
-{
-NdisAcquireSpinLock(gOvsCtrlLock);
-}
-
-static __inline VOID
-OvsReleaseEventQueueLock()
-{
- NdisReleaseSpinLock(gOvsCtrlLock);
-}
-
/*
* --
* Cleanup the event queue of the OpenInstance.
@@ -74,7 +62,7 @@ OvsCleanupEvent(POVS_OPEN_INSTANCE instance)
POVS_EVENT_QUEUE_ELEM elem;
PLIST_ENTRY link, next;
-OvsAcquireEventQueueLock();
+OvsAcquireCtrlLock();
RemoveEntryList(queue-queueLink);
ovsNumEventQueue--;
if (queue-pendingIrp) {
@@ -87,7 +75,7 @@ OvsCleanupEvent(POVS_OPEN_INSTANCE instance)
}
}
instance-eventQueue = NULL;
-OvsReleaseEventQueueLock();
+OvsReleaseCtrlLock();
if (irp) {
OvsCompleteIrpRequest(irp, 0, STATUS_SUCCESS);
}
@@ -125,7 +113,7 @@ OvsPostEvent(UINT32 portNo,
OVS_LOG_TRACE(Enter: portNo: %#x, status: %#x, portNo, status);
-OvsAcquireEventQueueLock();
+OvsAcquireCtrlLock();
LIST_FORALL(ovsEventQueue, link) {
queue = CONTAINING_RECORD(link, OVS_EVENT_QUEUE, queueLink);
@@ -170,7 +158,7 @@ OvsPostEvent(UINT32 portNo,
}
}
}
-OvsReleaseEventQueueLock();
+OvsReleaseCtrlLock();
while (!IsListEmpty(list)) {
entry = RemoveHeadList(list);
irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry);
@@ -214,7 +202,7 @@ OvsSubscribeEventIoctl(PFILE_OBJECT fileObject,
return STATUS_INVALID_PARAMETER;
}
-OvsAcquireEventQueueLock();
+OvsAcquireCtrlLock();
instance = OvsGetOpenInstance(fileObject, request-dpNo);
@@ -276,7 +264,7 @@ done_event_subscribe:
irp = NULL;
}
}
-OvsReleaseEventQueueLock();
+OvsReleaseCtrlLock();
if (irp) {
OvsCompleteIrpRequest(queue-pendingIrp, 0, STATUS_SUCCESS);
}
@@ -286,7 +274,7 @@ done_event_subscribe:
}
OvsFreeMemory(queue);
} else {
-OvsReleaseEventQueueLock();
+OvsReleaseCtrlLock();
}
OVS_LOG_TRACE(Exit: subscribe event with status: %#x., status);
return status;
@@ -337,10 +325,11 @@ OvsPollEventIoctl(PFILE_OBJECT fileObject,
}
poll = (POVS_EVENT_POLL)inputBuffer;
-OvsAcquireEventQueueLock();
+/* XXX: Verify if we really need a global lock here */
+OvsAcquireCtrlLock();
instance = OvsGetOpenInstance(fileObject, poll-dpNo);
if (instance == NULL) {
-OvsReleaseEventQueueLock();
+OvsReleaseCtrlLock();
*replyLen = 0;
OVS_LOG_TRACE(Exit: can not find Open instance);
return STATUS_INVALID_PARAMETER;
@@ -371,7 +360,7 @@ OvsPollEventIoctl(PFILE_OBJECT fileObject,
queue-numElems--;
}
event_poll_done:
-OvsReleaseEventQueueLock();
+OvsReleaseCtrlLock();
*replyLen = sizeof (OVS_EVENT_STATUS) +
numEntry * sizeof (OVS_EVENT_ENTRY);
OVS_LOG_TRACE(Exit: numEventPolled: %d, numEntry);
@@ -409,17 +398,19 @@ OvsCancelIrp(PDEVICE_OBJECT deviceObject,
if (fileObject == NULL) {
goto done;
}
-OvsAcquireEventQueueLock();
+
+/* XXX: Verify if we really need
[ovs-dev] [PATCH v1 2/2] datapath-windows: Transactional error fix for flow dump.
My changes for trasacation error handling for not needed for dump commands.
Fixed the same.
Signed-off-by: Ankur Sharma ankursha...@vmware.com
---
datapath-windows/ovsext/Flow.c | 50 +++---
1 file changed, 13 insertions(+), 37 deletions(-)
diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index f6e7bdb..3254223 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -381,48 +381,24 @@ OvsFlowNlGetCmdHandler(POVS_USER_PARAMS_CONTEXT
usrParamsCtx,
NTSTATUS rc = STATUS_SUCCESS;
NL_ERROR nlError = NL_ERROR_SUCCESS;
POVS_MESSAGE msgIn = (POVS_MESSAGE)usrParamsCtx-inputBuffer;
-POVS_MESSAGE msgOut = (POVS_MESSAGE)usrParamsCtx-outputBuffer;
-PNL_MSG_HDR nlMsgHdr = (msgIn-nlMsg);
-PGENL_MSG_HDR genlMsgHdr = (msgIn-genlMsg);
-POVS_HDR ovsHdr = (msgIn-ovsHdr);
-
-NL_BUFFER nlBuf;
-
-if (!(usrParamsCtx-outputBuffer)) {
-/* No output buffer */
-rc = STATUS_INVALID_BUFFER_SIZE;
-goto done;
-}
if (usrParamsCtx-devOp == OVS_TRANSACTION_DEV_OP) {
rc = _FlowNlGetCmdHandler(usrParamsCtx, replyLen);
-} else {
-rc = _FlowNlDumpCmdHandler(usrParamsCtx, replyLen);
-}
-if ((nlError != NL_ERROR_SUCCESS)
-(usrParamsCtx-outputBuffer)) {
-POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
- usrParamsCtx-outputBuffer;
-BuildErrorMsg(msgIn, msgError, nlError);
-*replyLen = msgError-nlMsg.nlmsgLen;
-rc = STATUS_SUCCESS;
-goto done;
-}
-
-if (rc == STATUS_SUCCESS) {
-NlBufInit(nlBuf, usrParamsCtx-outputBuffer,
- usrParamsCtx-outputLength);
-
-/* Prepare nl Msg headers */
-rc = NlFillOvsMsg(nlBuf, nlMsgHdr-nlmsgType, 0,
- nlMsgHdr-nlmsgSeq, nlMsgHdr-nlmsgPid,
- genlMsgHdr-cmd, OVS_FLOW_VERSION,
- ovsHdr-dp_ifindex);
-
-if (rc == STATUS_SUCCESS) {
-*replyLen = msgOut-nlMsg.nlmsgLen;
+/* No trasanctional errors as of now.
+ * If we have something then we need to convert rc to
+ * nlError. */
+if ((nlError != NL_ERROR_SUCCESS)
+(usrParamsCtx-outputBuffer)) {
+POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
+ usrParamsCtx-outputBuffer;
+BuildErrorMsg(msgIn, msgError, nlError);
+*replyLen = msgError-nlMsg.nlmsgLen;
+rc = STATUS_SUCCESS;
+goto done;
}
+} else {
+rc = _FlowNlDumpCmdHandler(usrParamsCtx, replyLen);
}
done:
--
1.9.1
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
