Re: [ovs-dev] [per-pmd ftb/cls 3/3] dpif-netdev: Add per-pmd flow-table/classifier.
> > Thanks for this patch. It's good that some of these locks are > being removed from the datapath. I reviewed the dpif-netdev.c > file. There is an XXX in fast_path_processing() - Can that be > resolved now as you have a per-core classifier or do I > misunderstand? Other than that the code is clean and I didn't > see any major issues. > > > > > Thx for the feedback!~ For the 'XXX' part, I'll conduct more experiment to > see if we could extend the critical section by moving mutex outside the loop. > However, I'm a bit worried that it could affect the revalidator execution. I just wanted to point it out. It may not need to be fixed as part of this patch set and could be a separate patch. I might look at it myself. > > We need the 'flow_mutex' because revalidators may delete flows and > > users may manually add/del flows via 'ovs-appctl dpctl/*' commands. > So, the extended critical section could lead to worse contention between > pmd thread and revalidator threads. > > > > > I did some tests with just single pmd and 30,000 > flows to see what kind of performance bump I could get with these > patches and I saw about a 30% increase in throughput (i didn't look > at latency). I guess even if there wasn't any contention on the stats > mutexes there should be a bump in performance because of the > overhead of locking the mute but I checked vtune and there was less > contention on mutexes. > > > > > I have never used vtune. But from analyzing using perf, if there is no > contention on the stats mutexes, the cpu util of locking/unlocking seems > negligible, overshadowed by other operations from the pmd thread main > loop. > > vtune is similar to perf but has nice graphs :) It also has a "locksandwaits" test which shows contention issues. > > > The flow_mutex is another one that I have seen cause contention, I > think this might be a bit trickier to remove. The way we did it in > OVDK was to queue up requests to alter the flow table and then > execute them when we had time (which was just intermittently). > Have > you thought about how to resolve this? > > > > > One thing we've discussed around is to make pmd thread revalidate flows > itself. We'll experiment on that. If it is implemented, we could then queue > up > user flow add/del operations and totally eliminate the flow mutex. It is > tricky > > to do it efficiently, we will do more research on that, I suppose there is a tradeoff which depends on how long validation takes. If the pmd thread is doing revalidation, it could introduce packet latency. Maybe there could be set preemption points in the revalidation that would yield the thread to packet processing. Either way, it's a discussion for another day. > > > Do all these make sense? Yes. Patch looks good. Tested-by: Mark D. Gray > > Thanks, > Alex Wang, > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Летающая фея: универсальный подарок для маленьких девочек!
Летающая фея: симпатичная фея, которая станет подружкой для вашей доченьки! Подробности тут ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] OVS Kernel Datapath development
On 12/07/14 at 08:47pm, Pravin Shelar wrote: > Since the beginning OVS kernel datapath development is primarily done > on external OVS repo. Now we have mostly synced upstream and external > OVS. So we have decided to change this process. New process is as > follows. > > 1. OVS feature development that involves kernel datapath should be > done on net-next tree datapath. > 2. Such feature patch series should be posted on netdev and ovs-dev > mailing list. > 3. Once review is done for entire series, kernel and OVS userspace > patches will be merged in respective repo. > 4. After the merge developer is suppose to send patches for external > kernel datapath along with old kernel compatibility code. So that we > can keep external datapath insync. +1 Just to be clear, by respective repo do you mean net-next/net or will you maintain a net-next branch on git.kernel.org and continue doing pull requests? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Support for MCAST_Snooping
On Mon, Dec 08, 2014 at 10:28:14PM +0530, Aman Kumar wrote: > So, Now my question is that does ovs snoops only to those ports which is > connected to host? OVS only snoops packets that pass through the OVS "normal" action. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 2/2] datapath-windows: return bool from NlFillOvs[Msg/Hdr]
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
---
datapath-windows/ovsext/Flow.c| 31 ++--
datapath-windows/ovsext/Netlink/Netlink.c |8 +++---
datapath-windows/ovsext/Netlink/Netlink.h | 12 +-
datapath-windows/ovsext/User.c| 12 +++---
datapath-windows/ovsext/Vport.c | 30 ++--
5 files changed, 53 insertions(+), 40 deletions(-)
diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index f50bb39..93f37a0 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -247,6 +247,7 @@ OvsFlowNlCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
UINT32 *replyLen)
{
NTSTATUS rc = STATUS_SUCCESS;
+BOOLEAN ok;
POVS_MESSAGE msgIn = (POVS_MESSAGE)usrParamsCtx->inputBuffer;
POVS_MESSAGE msgOut = (POVS_MESSAGE)usrParamsCtx->outputBuffer;
PNL_MSG_HDR nlMsgHdr = &(msgIn->nlMsg);
@@ -258,7 +259,6 @@ OvsFlowNlCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
OvsFlowStats stats;
struct ovs_flow_stats replyStats;
NL_ERROR nlError = NL_ERROR_SUCCESS;
-
NL_BUFFER nlBuf;
RtlZeroMemory(&mappedFlow, sizeof(OvsFlowPut));
@@ -294,13 +294,14 @@ OvsFlowNlCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
usrParamsCtx->outputLength);
/* Prepare nl Msg headers */
-rc = NlFillOvsMsg(&nlBuf, nlMsgHdr->nlmsgType, 0,
+ok = NlFillOvsMsg(&nlBuf, nlMsgHdr->nlmsgType, 0,
nlMsgHdr->nlmsgSeq, nlMsgHdr->nlmsgPid,
genlMsgHdr->cmd, OVS_FLOW_VERSION,
ovsHdr->dp_ifindex);
-
-if (rc == STATUS_SUCCESS) {
+if (ok) {
*replyLen = msgOut->nlMsg.nlmsgLen;
+} else {
+rc = STATUS_INVALID_BUFFER_SIZE;
}
}
@@ -330,13 +331,15 @@ OvsFlowNlCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
usrParamsCtx->outputLength);
/* Prepare nl Msg headers */
-rc = NlFillOvsMsg(&nlBuf, nlMsgHdr->nlmsgType, 0,
+ok = NlFillOvsMsg(&nlBuf, nlMsgHdr->nlmsgType, 0,
nlMsgHdr->nlmsgSeq, nlMsgHdr->nlmsgPid,
genlMsgHdr->cmd, OVS_FLOW_VERSION,
ovsHdr->dp_ifindex);
-
-if (rc != STATUS_SUCCESS) {
+if (!ok) {
+rc = STATUS_INVALID_BUFFER_SIZE;
goto done;
+} else {
+rc = STATUS_SUCCESS;
}
/* Append OVS_FLOW_ATTR_STATS attribute */
@@ -586,15 +589,20 @@ _FlowNlDumpCmdHandler(POVS_USER_PARAMS_CONTEXT
usrParamsCtx,
/* Done with Dump, send NLMSG_DONE */
if (!(dumpOutput.n)) {
+BOOLEAN ok;
+
OVS_LOG_INFO("Dump Done");
nlMsgOutHdr = (PNL_MSG_HDR)(NlBufAt(&nlBuf, NlBufSize(&nlBuf), 0));
-rc = NlFillNlHdr(&nlBuf, NLMSG_DONE, NLM_F_MULTI,
+ok = NlFillNlHdr(&nlBuf, NLMSG_DONE, NLM_F_MULTI,
nlMsgHdr->nlmsgSeq, nlMsgHdr->nlmsgPid);
-if (rc != STATUS_SUCCESS) {
+if (!ok) {
+rc = STATUS_INVALID_BUFFER_SIZE;
OVS_LOG_ERROR("Unable to prepare DUMP_DONE reply.");
break;
+} else {
+rc = STATUS_SUCCESS;
}
NlMsgAlignSize(nlMsgOutHdr);
@@ -603,17 +611,18 @@ _FlowNlDumpCmdHandler(POVS_USER_PARAMS_CONTEXT
usrParamsCtx,
FreeUserDumpState(instance);
break;
} else {
+BOOLEAN ok;
hdrOffset = NlBufSize(&nlBuf);
nlMsgOutHdr = (PNL_MSG_HDR)(NlBufAt(&nlBuf, hdrOffset, 0));
/* Netlink header */
-rc = NlFillOvsMsg(&nlBuf, nlMsgHdr->nlmsgType, NLM_F_MULTI,
+ok = NlFillOvsMsg(&nlBuf, nlMsgHdr->nlmsgType, NLM_F_MULTI,
nlMsgHdr->nlmsgSeq, nlMsgHdr->nlmsgPid,
genlMsgHdr->cmd, genlMsgHdr->version,
ovsHdr->dp_ifindex);
-if (rc != STATUS_SUCCESS) {
+if (!ok) {
/* Reset rc to success so that we can
* send already added messages to user space. */
rc = STATUS_SUCCESS;
diff --git a/datapath-windows/ovsext/Netlink/Netlink.c
b/datapath-windows/ovsext/Netlink/Netlink.c
index 0d48d08..589e3a1 100644
--- a/datapath-windows/ovsext/Netlink/Netlink.c
+++ b/datapath-windows/ovsext/Netlink/Netlink.c
@@ -39,7 +39,7 @@
* Attributes should be added by caller.
* ---
*/
-NTSTATUS
+BOOLEAN
NlFillOvsMsg(PNL_BUFFER nlBuf, UINT16 nlmsgType,
UINT16 nlmsgFlags, UINT32 nlmsgSeq,
[ovs-dev] [PATCH 1/2] datapath-windows: refactor BuildReplyMsgFromMsgIn & BuildErrorMsg
In this patch, we consolidate code in Netlink.c.
Signed-off-by: Nithin Raju
---
datapath-windows/ovsext/Datapath.c|2 +-
datapath-windows/ovsext/Flow.c|4 +-
datapath-windows/ovsext/Netlink/Netlink.c | 40 -
datapath-windows/ovsext/Netlink/Netlink.h |6 +---
datapath-windows/ovsext/User.c|2 +-
datapath-windows/ovsext/Vport.c | 28 +---
6 files changed, 30 insertions(+), 52 deletions(-)
diff --git a/datapath-windows/ovsext/Datapath.c
b/datapath-windows/ovsext/Datapath.c
index f6e6e50..af8d818 100644
--- a/datapath-windows/ovsext/Datapath.c
+++ b/datapath-windows/ovsext/Datapath.c
@@ -1324,7 +1324,7 @@ cleanup:
POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
usrParamsCtx->outputBuffer;
-BuildErrorMsg(msgIn, msgError, nlError);
+NlBuildErrorMsg(msgIn, msgError, nlError);
*replyLen = msgError->nlMsg.nlmsgLen;
}
diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index f47d469..f50bb39 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -355,7 +355,7 @@ done:
if (nlError != NL_ERROR_SUCCESS) {
POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
usrParamsCtx->outputBuffer;
-BuildErrorMsg(msgIn, msgError, nlError);
+NlBuildErrorMsg(msgIn, msgError, nlError);
*replyLen = msgError->nlMsg.nlmsgLen;
rc = STATUS_SUCCESS;
}
@@ -387,7 +387,7 @@ OvsFlowNlGetCmdHandler(POVS_USER_PARAMS_CONTEXT
usrParamsCtx,
(usrParamsCtx->outputBuffer)) {
POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
usrParamsCtx->outputBuffer;
-BuildErrorMsg(msgIn, msgError, nlError);
+NlBuildErrorMsg(msgIn, msgError, nlError);
*replyLen = msgError->nlMsg.nlmsgLen;
status = STATUS_SUCCESS;
goto done;
diff --git a/datapath-windows/ovsext/Netlink/Netlink.c
b/datapath-windows/ovsext/Netlink/Netlink.c
index 7633f2f..0d48d08 100644
--- a/datapath-windows/ovsext/Netlink/Netlink.c
+++ b/datapath-windows/ovsext/Netlink/Netlink.c
@@ -102,41 +102,23 @@ NlFillNlHdr(PNL_BUFFER nlBuf, UINT16 nlmsgType,
return writeOk ? STATUS_SUCCESS : STATUS_INVALID_BUFFER_SIZE;
}
-static VOID
-BuildMsgOut(POVS_MESSAGE msgIn, POVS_MESSAGE msgOut, UINT16 type,
-UINT32 length, UINT16 flags)
-{
-msgOut->nlMsg.nlmsgType = type;
-msgOut->nlMsg.nlmsgFlags = flags;
-msgOut->nlMsg.nlmsgSeq = msgIn->nlMsg.nlmsgSeq;
-msgOut->nlMsg.nlmsgPid = msgIn->nlMsg.nlmsgPid;
-msgOut->nlMsg.nlmsgLen = length;
-
-msgOut->genlMsg.cmd = msgIn->genlMsg.cmd;
-msgOut->genlMsg.version = msgIn->genlMsg.version;
-msgOut->genlMsg.reserved = 0;
-}
-
/*
- * XXX: should move out these functions to a Netlink.c or to a OvsMessage.c
- * or even make them inlined functions in Datapath.h. Can be done after the
- * first sprint once we have more code to refactor.
+ * ---
+ * Prepare a 'OVS_MESSAGE_ERROR' message.
+ * ---
*/
VOID
-BuildReplyMsgFromMsgIn(POVS_MESSAGE msgIn, POVS_MESSAGE msgOut, UINT16 flags)
+NlBuildErrorMsg(POVS_MESSAGE msgIn, POVS_MESSAGE_ERROR msgError, UINT
errorCode)
{
-BuildMsgOut(msgIn, msgOut, msgIn->nlMsg.nlmsgType, sizeof(OVS_MESSAGE),
-flags);
-}
+NL_BUFFER nlBuffer;
-VOID
-BuildErrorMsg(POVS_MESSAGE msgIn, POVS_MESSAGE_ERROR msgOut, UINT errorCode)
-{
-BuildMsgOut(msgIn, (POVS_MESSAGE)msgOut, NLMSG_ERROR,
-sizeof(OVS_MESSAGE_ERROR), 0);
+NlBufInit(&nlBuffer, (PCHAR)msgError, sizeof *msgError);
+NlFillNlHdr(&nlBuffer, NLMSG_ERROR, 0,
+msgIn->nlMsg.nlmsgSeq, msgIn->nlMsg.nlmsgPid);
-msgOut->errorMsg.error = errorCode;
-msgOut->errorMsg.nlMsg = msgIn->nlMsg;
+msgError->errorMsg.error = errorCode;
+msgError->errorMsg.nlMsg = msgIn->nlMsg;
+msgError->nlMsg.nlmsgLen = sizeof(OVS_MESSAGE_ERROR);
}
/*
diff --git a/datapath-windows/ovsext/Netlink/Netlink.h
b/datapath-windows/ovsext/Netlink/Netlink.h
index 18e40b1..a7a53e0 100644
--- a/datapath-windows/ovsext/Netlink/Netlink.h
+++ b/datapath-windows/ovsext/Netlink/Netlink.h
@@ -94,10 +94,8 @@ NTSTATUS NlFillNlHdr(PNL_BUFFER nlBuf,
UINT16 nlmsgType, UINT16 nlmsgFlags,
UINT32 nlmsgSeq, UINT32 nlmsgPid);
-VOID BuildReplyMsgFromMsgIn(POVS_MESSAGE msgIn, POVS_MESSAGE msgOut,
-UINT16 flags);
-VOID BuildErrorMsg(POVS_MESSAGE msgIn, POVS_MESSAGE_ERROR msgOut,
- UINT errorCode);
+VOID NlBuildErrorMsg(POVS_MESSAGE msgIn, POVS_MESSAGE_ERROR msgOut,
+ UINT errorCode);
/* Netlink message accessing the payload */
Re: [ovs-dev] [PATCH 3/3] datapath-windows: refactor BuildReplyMsgFromMsgIn & BuildErrorMsg
On Dec 3, 2014, at 10:32 AM, Nithin Raju wrote: > On Dec 3, 2014, at 10:18 AM, Eitan Eliahu > wrote: > >> >> Hi Nithin, >> It may be out of the scope of this change but for consistency reason all NL >> function should return BOOLEAN rather than NTSTATUS. >> This should apply NlFillOvsMsg() and NlFillNlHdr() too. >> >> BOOLEAN ok; >> +ok = NlFillOvsMsg(&nlBuffer, msgIn->nlMsg.nlmsgType, NLM_F_MULTI, >> >> But the function signature is >> NTSTATUS NlFillOvsMsg(PNL_BUFFER nlBuf, UINT16 nlmsgType,: > > Not a problem. Thanks for the suggestion. I'll send out a v2 with the > suggested change. Eitan, I created a new patch for the change you suggested, and sent it for review. It is a 2 part series. thanks, -- Nithin ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] bug in flow stats for VLAN acceleration?
Motonori Shindo (CCed) reported to me recently that NetFlow does not include VLAN headers in the byte counts that it exports. Taking a look at the kernel datapath code, I see that ovs_flow_stats_update() accounts raw skb->len to byte counters. I suspect that it should add 4 if a VLAN header was present but removed by VLAN acceleration. Comments? Thanks, Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] bug in flow stats for VLAN acceleration?
On Mon, Dec 8, 2014 at 9:58 AM, Ben Pfaff wrote: > Motonori Shindo (CCed) reported to me recently that NetFlow does not > include VLAN headers in the byte counts that it exports. Taking a > look at the kernel datapath code, I see that ovs_flow_stats_update() > accounts raw skb->len to byte counters. I suspect that it should add > 4 if a VLAN header was present but removed by VLAN acceleration. Presumably we should also do this for port stats as well to be consistent. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] tests/classifier: Make test work in big-endian systems.
On Dec 5, 2014, at 10:24 AM, Ben Pfaff wrote: > On Wed, Dec 03, 2014 at 01:21:48PM -0800, Jarno Rajahalme wrote: >> Change a test so that the result will be the same in both >> little-endian and big-endian systems. > > ...by editing the test case so that only one bit differs? > >> Reported-by: Mijo Safradin >> Signed-off-by: Jarno Rajahalme > > Acked-by: Ben Pfaff Thanks for the review, pushed with an updated commit message. Jarno ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] OVS Kernel Datapath development
On Mon, Dec 8, 2014 at 9:15 AM, Thomas Graf wrote: > On 12/07/14 at 08:47pm, Pravin Shelar wrote: >> Since the beginning OVS kernel datapath development is primarily done >> on external OVS repo. Now we have mostly synced upstream and external >> OVS. So we have decided to change this process. New process is as >> follows. >> >> 1. OVS feature development that involves kernel datapath should be >> done on net-next tree datapath. >> 2. Such feature patch series should be posted on netdev and ovs-dev >> mailing list. >> 3. Once review is done for entire series, kernel and OVS userspace >> patches will be merged in respective repo. >> 4. After the merge developer is suppose to send patches for external >> kernel datapath along with old kernel compatibility code. So that we >> can keep external datapath insync. > > +1 > > Just to be clear, by respective repo do you mean net-next/net or will > you maintain a net-next branch on git.kernel.org and continue doing > pull requests? OVS patches will directly go to net-next/net tree. I am not planning on maintaining any tree on git.kernel.org. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/5] ovs-router: non-Linux support
On Wed, Dec 3, 2014 at 2:31 AM, YAMAMOTO Takashi wrote:
> Refactor ovs-router so that it can work with non-Linux platforms
> at least in some extent, using the existing route-table code as
> a fallback. Known restriction: for such platforms, "ovs/router/show"
> command does not show "Cached" kernel routes.
>
> Signed-off-by: YAMAMOTO Takashi
LGTM
Acked-by: Pravin B Shelar
> ---
> README-native-tunneling.md | 2 --
> lib/automake.mk| 3 +--
> lib/ovs-router-linux.h | 40
> lib/ovs-router.c | 4 ++--
> lib/ovs-router.h | 3 +++
> lib/route-table-bsd.c | 8 ++--
> lib/route-table-stub.c | 11 ---
> lib/route-table.c | 10 +-
> lib/route-table.h | 1 +
> tests/tunnel-push-pop.at | 4
> 10 files changed, 22 insertions(+), 64 deletions(-)
> delete mode 100644 lib/ovs-router-linux.h
>
> diff --git a/README-native-tunneling.md b/README-native-tunneling.md
> index 7666dcc..0ffd82b 100644
> --- a/README-native-tunneling.md
> +++ b/README-native-tunneling.md
> @@ -51,8 +51,6 @@ There are following commands that shows internal tables:
> Tunneling related commands:
> ===
> Tunnel routing table:
> -These commands are only available on Linux platform.
> -
> To Add route:
> ovs-appctl ovs/route/add /
>
> To see all routes configured:
> diff --git a/lib/automake.mk b/lib/automake.mk
> index 0b2d823..a98f7cc 100644
> --- a/lib/automake.mk
> +++ b/lib/automake.mk
> @@ -163,6 +163,7 @@ lib_libopenvswitch_la_SOURCES = \
> lib/ovs-rcu.c \
> lib/ovs-rcu.h \
> lib/ovs-router.h \
> + lib/ovs-router.c \
> lib/ovs-thread.c \
> lib/ovs-thread.h \
> lib/ovsdb-data.c \
> @@ -331,8 +332,6 @@ lib_libopenvswitch_la_SOURCES += \
> lib/netlink-socket.h \
> lib/ovs-numa.c \
> lib/ovs-numa.h \
> - lib/ovs-router.c \
> - lib/ovs-router-linux.h \
> lib/rtnetlink-link.c \
> lib/rtnetlink-link.h \
> lib/route-table.c \
> diff --git a/lib/ovs-router-linux.h b/lib/ovs-router-linux.h
> deleted file mode 100644
> index f60f403..000
> --- a/lib/ovs-router-linux.h
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -/*
> - * Copyright (c) 2014 Nicira, Inc.
> - *
> - * Licensed under the Apache License, Version 2.0 (the "License");
> - * you may not use this file except in compliance with the License.
> - * You may obtain a copy of the License at:
> - *
> - * http://www.apache.org/licenses/LICENSE-2.0
> - *
> - * Unless required by applicable law or agreed to in writing, software
> - * distributed under the License is distributed on an "AS IS" BASIS,
> - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> - * See the License for the specific language governing permissions and
> - * limitations under the License.
> - */
> -
> -#ifndef OVS_TNL_ROUTER_LINUX_H
> -#define OVS_TNL_ROUTER_LINUX_H 1
> -
> -#include
> -#include
> -#include
> -
> -#include "packets.h"
> -#include "timeval.h"
> -#include "unixctl.h"
> -#include "util.h"
> -
> -#ifdef __cplusplus
> -extern "C" {
> -#endif
> -
> -void ovs_router_insert(ovs_be32 ip_dst, uint8_t plen, const char
> output_bridge[],
> - ovs_be32 gw);
> -void ovs_router_flush(void);
> -#ifdef __cplusplus
> -}
> -#endif
> -
> -#endif
> diff --git a/lib/ovs-router.c b/lib/ovs-router.c
> index e4f8a08..b095f68 100644
> --- a/lib/ovs-router.c
> +++ b/lib/ovs-router.c
> @@ -35,8 +35,8 @@
> #include "packets.h"
> #include "seq.h"
> #include "ovs-router.h"
> -#include "ovs-router-linux.h"
> #include "ovs-thread.h"
> +#include "route-table.h"
> #include "unixctl.h"
> #include "util.h"
>
> @@ -76,7 +76,7 @@ ovs_router_lookup(ovs_be32 ip_dst, char output_bridge[],
> ovs_be32 *gw)
> *gw = p->gw;
> return true;
> }
> -return false;
> +return route_table_fallback_lookup(ip_dst, output_bridge, gw);
> }
>
> static void
> diff --git a/lib/ovs-router.h b/lib/ovs-router.h
> index b0042cc..cc0ebc2 100644
> --- a/lib/ovs-router.h
> +++ b/lib/ovs-router.h
> @@ -25,6 +25,9 @@ extern "C" {
>
> bool ovs_router_lookup(ovs_be32 ip_dst, char out_dev[], ovs_be32 *gw);
> void ovs_router_init(void);
> +void ovs_router_insert(ovs_be32 ip_dst, uint8_t plen,
> + const char output_bridge[], ovs_be32 gw);
> +void ovs_router_flush(void);
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/route-table-bsd.c b/lib/route-table-bsd.c
> index 6d5fe5c..09f9894 100644
> --- a/lib/route-table-bsd.c
> +++ b/lib/route-table-bsd.c
> @@ -33,7 +33,7 @@
> #include "util.h"
>
> bool
> -ovs_router_lookup(ovs_be32 ip, char name[], ovs_be32 *gw)
> +route_table_fallback_lookup(ovs_be32 ip, char name[], ovs_be32 *gw)
> {
> struct {
> struct rt_msghdr rtm;
> @@ -116,6 +116,7 @@ route_table_get_change_seq(void)
> void
> route_table_init(voi
Re: [ovs-dev] [PATCH 3/5] ovs-router: Add "ovs/route/lookup" command
On Wed, Dec 3, 2014 at 2:31 AM, YAMAMOTO Takashi wrote:
> This command is useful at least for testing.
>
> Example output:
> % ovs-appctl ovs/route/lookup '10.0.0.1'
> gateway 172.17.0.254
> dev wm0
> %
>
Can you add documentation for new command?
> Signed-off-by: YAMAMOTO Takashi
otherwise looks good.
Acked-by: Pravin B Shelar
> ---
> lib/ovs-router.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/lib/ovs-router.c b/lib/ovs-router.c
> index b095f68..a121354 100644
> --- a/lib/ovs-router.c
> +++ b/lib/ovs-router.c
> @@ -260,6 +260,31 @@ ovs_router_show(struct unixctl_conn *conn, int argc
> OVS_UNUSED,
> ds_destroy(&ds);
> }
>
> +static void
> +ovs_router_lookup_cmd(struct unixctl_conn *conn, int argc OVS_UNUSED,
> + const char *argv[], void *aux OVS_UNUSED)
> +{
> +ovs_be32 ip;
> +unsigned int plen;
> +
> +if (scan_ipv4_route(argv[1], &ip, &plen) && plen == 32) {
> +char iface[IFNAMSIZ];
> +ovs_be32 gw;
> +
> +if (ovs_router_lookup(ip, iface, &gw)) {
> +struct ds ds = DS_EMPTY_INITIALIZER;
> +
> +ds_put_format(&ds, "gateway " IP_FMT "\n", IP_ARGS(gw));
> +ds_put_format(&ds, "dev %s\n", iface);
> +unixctl_command_reply(conn, ds_cstr(&ds));
> +} else {
> +unixctl_command_reply(conn, "Not found");
> +}
> +} else {
> +unixctl_command_reply(conn, "Invalid parameters");
> +}
> +}
> +
> void
> ovs_router_flush(void)
> {
> @@ -289,4 +314,6 @@ ovs_router_init(void)
> unixctl_command_register("ovs/route/show", "", 0, 0, ovs_router_show,
> NULL);
> unixctl_command_register("ovs/route/del", "ipv4_addr/prefix_len", 1, 1,
> ovs_router_del,
> NULL);
> +unixctl_command_register("ovs/route/lookup", "ipv4_addr", 1, 1,
> + ovs_router_lookup_cmd, NULL);
> }
> --
> 1.9.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] OFtest--time for a new run?
Ok that explains why the barrier isn't working for that test. Sorry about the delay. Pl find a summary of the remaining failures with the associated logs. Thanks. On Fri, Dec 5, 2014 at 11:24 AM, Ben Pfaff wrote: > Currently we don't synchronize barriers and revalidation at all. If > we decide that > this is important for correctness, we will have to write new code to > implement it. > > On Fri, Dec 5, 2014 at 11:21 AM, Madhu Challa > wrote: > > Yes it does get a barrier reply. Pl see the logs below. We do see > > revalidator21 wakeup, but may be we are sending the barrier reply before > the > > revalidation completes ? I am not sure how the barrier request > synchronizes > > with the revalidation. > > > > Thanks. > > > > 2014-12-05T19:08:01.710Z|00439|vconn|DBG|tcp:127.0.0.1:6653: received: > > OFPT_FLOW_MOD (xid=0x20e86f61): ADD > > > priority=1250,tcp,in_port=1,vlan_tci=0x,dl_src=00:06:07:08:09:0a,nw_src=192.168.0.1,nw_dst=192.168.0.2,nw_tos=0,tp_src=1234,tp_dst=80 > > out_port:0 actions=output:3 > > 2014-12-05T19:08:01.710Z|00440|ofproto_dpif|DBG|need revalidate in > > ofproto_wait_cb() > > 2014-12-05T19:08:01.710Z|00441|poll_loop|DBG|wakeup due to [POLLIN] on > fd 57 > > (127.0.0.1:55146<->127.0.0.1:6653) at lib/stream-fd.c:155 > > 2014-12-05T19:08:01.710Z|00442|vconn|DBG|tcp:127.0.0.1:6653: received: > > OFPT_BARRIER_REQUEST (xid=0xec5c5cb4): > > 2014-12-05T19:08:01.710Z|00451|poll_loop(revalidator21)|DBG|wakeup due to > > [POLLIN] on fd 39 (FIFO pipe:[64669378]) at > > ofproto/ofproto-dpif-upcall.c:790 (0% CPU usage) > > 2014-12-05T19:08:01.710Z|00443|vconn|DBG|tcp:127.0.0.1:6653: sent > (Success): > > OFPT_BARRIER_REPLY (xid=0xec5c5cb4): > > 2014-12-05T19:08:01.710Z|00452|dpif(revalidator21)|DBG|dummy@ovs-dummy: > > flow_dump ufid:eb2b8b89e6a933cfa8e8fedabccad013 , packets:0, > bytes:0, > > used:never > > 2014-12-05T19:08:01.710Z|00296|poll_loop(revalidator23)|DBG|wakeup due to > > [POLLIN] on fd 37 (FIFO pipe:[64528939]) at lib/ovs-thread.c:302 (0% CPU > > usage) > > 2014-12-05T19:08:01.710Z|00298|poll_loop(revalidator25)|DBG|wakeup due to > > [POLLIN] on fd 45 (FIFO pipe:[61793514]) at lib/ovs-thread.c:302 > > 2014-12-05T19:08:01.710Z|00297|dpif(revalidator23)|DBG|dummy@ovs-dummy: > > dumped all flows > > 2014-12-05T19:08:01.710Z|00271|poll_loop(revalidator24)|DBG|wakeup due to > > [POLLIN] on fd 41 (FIFO pipe:[64670832]) at lib/ovs-thread.c:302 > > 2014-12-05T19:08:01.710Z|00453|dpif(revalidator21)|DBG|dummy@ovs-dummy: > > dumped all flows > > 2014-12-05T19:08:01.710Z|00299|dpif(revalidator25)|DBG|dummy@ovs-dummy: > > dumped all flows > > 2014-12-05T19:08:01.710Z|00272|dpif(revalidator24)|DBG|dummy@ovs-dummy: > > dumped all flows > > > > On Fri, Dec 5, 2014 at 9:42 AM, Ben Pfaff wrote: > >> > >> On Thu, Dec 4, 2014 at 3:17 PM, Madhu Challa > >> wrote: > >> > 6 of the tests fail because we failed to revalidate the flows fast > >> > enough. > >> > > >> > e.g the pktact priority tests > >> > add flow in_port=1, match M actions=output:2 with priority 250 > >> > sends a packet and verifies its egress port is 2 > >> > add flow in_port=1, match M actions=output:3 with priority 1250 > >> > sends a packet and verifies its egress port is 3 (which fails) > >> > >> Hmm, if there's a barrier message in there then there might be a > >> reasonable > >> claim that Open vSwitch should complete revalidation. Is there a > barrier? > > > > > > > > -- > "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 > FAIL: pktact.WildcardPriorityWithDelete FAIL: pktact.WildcardPriority FAIL: pktact.FloodMinusPort FAIL: pktact.SingleWildcardMatchPriority FAIL: detailed_contr_sw_messages.ModifyAction FAIL: detailed_contr_sw_messages.Outport2 FAIL: detailed_contr_sw_messages.StrictModifyAction - All these tests should pass if we complete revalidation before barrier reply. - other than this there is no bug here. = FAIL: detailed_contr_sw_messages.DeleteEmerFlow Looks like ovs does not support this feature. - Inserting a emergency flow with send_flow_removed flag set, Expecting no flow_removed_message on the deletion of the emergency flow. - Received error message: xid=1734012925 type=OFPET_FLOW_MOD_FAILED (3) code=OFPFMFC_ALL_TABLES_FULL (0), Got flow_mod_failed_error_msg message 2014-12-05T08:00:15.680Z|02783|vconn|DBG|tcp:127.0.0.1:6653: received: OFPT_FLOW_MOD (xid=0xa429a45d): ***decode error: OFPFMFC_TABLE_FULL*** 2014-12-05T08:00:15.680Z|02784|connmgr|INFO|br0<->tcp:127.0.0.1:6653: sending OFPFMFC_TABLE_FULL error reply to OFPT_FLOW_MOD message 2014-12-05T08:00:15.680Z|02785|vconn|DBG|tcp:127.0.0.1:6653: sent (Success): OFPT_ERROR (xid=0xa429a45d): OFPFMFC_TABLE_FULL OFPT_FLOW_MOD (xid=0xa429a45d): (***truncated to 64 bytes from 80***) 01 0e 00 50 a4 29 a4 5d-00 00 00 01 00 01 00 06 |...P.).]| 0010 07 08 09 0a 00 01 02 03-04 05 ff ff 00 00
Re: [ovs-dev] [PATCH 1/3] auto-attach: Initial support for Auto-Attach standard
On Fri, Nov 14, 2014 at 07:42:07AM -0500, drfl...@avaya.com wrote: > From: Dennis Flynn > > 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 provided to include this > new > Auto-Attach 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 > Signed-off-by: Dennis Flynn Sorry for the long delay in review. lldp.c and lldpd.c provoke a lot of warnings from "sparse": ../lib/lldp/lldpd.c:79:12: warning: Using plain integer as NULL pointer ../lib/lldp/lldpd.c:214:39: warning: Using plain integer as NULL pointer ../lib/lldp/lldpd.c:214:59: warning: Using plain integer as NULL pointer ../lib/lldp/lldpd.c:214:80: warning: Using plain integer as NULL pointer ../lib/lldp/lldp.c:183:11: warning: incorrect type in assignment (different base types) ../lib/lldp/lldp.c:183:11:expected unsigned short static [unsigned] [toplevel] [usertype] f_uint16 ../lib/lldp/lldp.c:183:11:got restricted ovs_be16 ../lib/lldp/lldp.c:186:11: warning: invalid assignment: |= ../lib/lldp/lldp.c:186:11:left side has type unsigned short ../lib/lldp/lldp.c:186:11:right side has type restricted ovs_be16 ../lib/lldp/lldp.c:191:11: warning: incorrect type in assignment (different base types) ../lib/lldp/lldp.c:191:11:expected unsigned short static [unsigned] [toplevel] [assigned] [usertype] f_uint16 ../lib/lldp/lldp.c:191:11:got restricted ovs_be16 ../lib/lldp/lldp.c:194:11: warning: invalid assignment: |= ../lib/lldp/lldp.c:194:11:left side has type unsigned short ../lib/lldp/lldp.c:194:11:right side has type restricted ovs_be16 ../lib/lldp/lldp.c:199:11: warning: incorrect type in assignment (different base types) ../lib/lldp/lldp.c:199:11:expected unsigned short static [unsigned] [toplevel] [assigned] [usertype] f_uint16 ../lib/lldp/lldp.c:199:11:got restricted ovs_be16 ../lib/lldp/lldp.c:200:11: warning: incorrect type in assignment (different base types) ../lib/lldp/lldp.c:200:11:expected unsigned short static [unsigned] [toplevel] [assigned] [usertype] f_uint16 ../lib/lldp/lldp.c:200:11:got restricted ovs_be16 ../lib/lldp/lldp.c:201:11: warning: invalid assignment: |= ../lib/lldp/lldp.c:201:11:left side has type unsigned short ../lib/lldp/lldp.c:201:11:right side has type restricted ovs_be16 ../lib/lldp/lldp.c:207:15: warning: incorrect type in assignment (different base types) ../lib/lldp/lldp.c:207:15:expected unsigned short static [unsigned] [toplevel] [assigned] [usertype] f_uint16 ../lib/lldp/lldp.c:207:15:got restricted ovs_be16 ../lib/lldp/lldp.c:209:15: warning: invalid assignment: |= ../lib/lldp/lldp.c:209:15:left side has type unsigned short ../lib/lldp/lldp.c:209:15:right side has type restricted ovs_be16 ../lib/lldp/lldp.c:216:15: warning: incorrect type in assignment (different base types) ../lib/lldp/lldp.c:216:15:expected unsigned short static [unsigned] [toplevel] [assigned] [usertype] f_uint16 ../lib/lldp/lldp.c:216:15:got restricted ovs_be16 ../lib/lldp/lldp.c:218:15: warning: invalid assignment: |= ../lib/lldp/lldp.c:218:15:left side has type unsigned short ../lib/lldp/lldp.c:218:15:right side has type restricted ovs_be16 ../lib/lldp/lldp.c:224:11: warning: incorrect type in assignment (different base types) ../lib/lldp/lldp.c:224:11:expected unsigned short static [unsigned] [toplevel] [assigned] [usertype] f_uint16 ../lib/lldp/lldp.c:224:11:got restricted ovs_be16 ../lib/lldp/lldp.c:225:11: warning: incorrect type in assignment (different base types) ../lib/lldp/lldp.c:225:11:expected unsigned short static [unsigned] [toplevel] [assigned] [usertype] f_uint16 ../lib/lldp/lldp.c:225:11:got restricted ovs_be16 ../lib/lldp/lldp.c:226:11: warning: incorrect type in assignment (different base types) ../lib/lldp/lldp.c:226:11:expected unsigned short static [unsigned] [toplevel] [assigned] [usertype] f_uint16 ../lib/lldp/lldp.c:226:11:got restricted ovs_be16 ../l
Re: [ovs-dev] [PATCH 1/2] ovs-command-completion: Fix unwanted whitespace.
On 25 November 2014 at 18:17, Alex Wang wrote: > This commit fixes unwanted whitespace in the ovs > bash completion script output. > > Signed-off-by: Alex Wang Did you get review for this? Acked-by: Joe Stringer ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Support for MCAST_Snooping
On Mon, Dec 08, 2014 at 10:28:14PM +0530, Aman Kumar wrote: > Hi all, > > Thanks again, because of your help it is working fine but i have a problem > with 2 compute nodes(each one is having different OVS), > below is the complete scenario. > [image: Inline image 1] > > Here, when receiver VM1 sends IGMP v2 reports, it reaches to OVS2 also but > only OVS1 is able to Snoops that but OVS2 is not able to snoop. > So, Now my question is that does ovs snoops only to those ports which is > connected to host? > Can't it snoop the other port which is not connected to host but IGMP > report is coming from there? > here br-tun and br-int is bridges on ovs, i have enabled the snooping on > br-int I am confused with your problem description. If you configured the port as multicast flood port or if it is a multicast router port, then the bridge will not learn any Report coming there because they are automatically used to send multicast packets anyway. Flood ports are configured by the admin. The mcast router port is automatically set when a Query is received (you can check in the mdb). Other than that, the bridge should snoop any packet passing through it using the action NORMAL regardless if it's connected to a host or not. fbl ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 1/2] ovs-command-completion: Fix unwanted whitespace.
Nope, do need a review (both patches) ~ thx~ On Mon, Dec 8, 2014 at 11:32 AM, Joe Stringer wrote: > On 25 November 2014 at 18:17, Alex Wang wrote: > > This commit fixes unwanted whitespace in the ovs > > bash completion script output. > > > > Signed-off-by: Alex Wang > > Did you get review for this? > > Acked-by: Joe Stringer > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/3] auto-attach: Add auto-attach support to ofproto layer
On Fri, Nov 14, 2014 at 07:42:08AM -0500, drfl...@avaya.com wrote: > From: Dennis Flynn > > Signed-off-by: Ludovic Beliveau > Signed-off-by: Dennis Flynn Thanks for the second version! In monitor_mport_run(), I think it would be better to put the result of each of the *_wake_time() calls into a temporary variable, rather than to pass them directly to the MIN macro, because calling these functions twice is expensive and because they don't necessarily return exactly the same value two times in a row. (I realize that this is partly an existing problem but it's best not to make it worse.) In ofproto-provider.h, the comment on get_lldp_status talks about a 'status->rmps' member that does not exist. In ofproto-provider.h there is some inconsistent indentation: +/* If 's' is nonnull, this function registers a mapping associated with + * client data pointer 'aux' in 'ofproto'. If 'aux' is already registered +* then this function updates its configuration to 's'. Otherwise, this +* function registers a new mapping. + * + * An implementation that does not support mapping at all may set + * it to NULL or return EOPNOTSUPP. An implementation that supports and: +/* If 's' is nonnull, this function unregisters a mapping associated with + * client data pointer 'aux' in 'ofproto'. If 'aux' is already registered +* then this function updates its configuration to 's'. Otherwise, this +* function unregisters a new mapping. + * The comments on aa_get_vlan_queued() and on the member function in struct ofproto_class should explain what's in the output list. Thanks, Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 0/8] OpenFlow 1.4 bundles fixes.
This series improves the OpenFlow 1.4 bundles code to follow the spec more closely. This is work in progress, as actual commits are still not supported. Jarno Rajahalme (8): connmgr: Dealloc 'bundles' in ofconn_destroy(). rconn: Make OF 1.4 bundle messages 'admitted'. OF1.4 bundles: Verify xids. bundles: Reject bundle add with bad flags. bundles: Reject unbundlable messages. ofproto: Reject slave controllers for bundle messages. bundles: Clean up bundle commit. bundles: Validate bundled messages. lib/ofp-parse.c|1 - lib/ofp-print.c|2 +- lib/ofp-util.c | 103 +++- lib/ofp-util.h |5 ++- lib/rconn.c|4 +- ofproto/bundles.c | 53 +-- ofproto/bundles.h | 48 ofproto/connmgr.c |1 + ofproto/ofproto.c | 45 ++- tests/ofp-print.at | 57 + 10 files changed, 269 insertions(+), 50 deletions(-) -- 1.7.10.4 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 7/8] bundles: Clean up bundle commit.
This fixes ofp_bundle_commit() in two ways:
- Always remove the bundle regardless of the error condition.
- A commit of an empty bundle must be successful.
The actual commit is still not supported.
Signed-off-by: Jarno Rajahalme
---
lib/ofp-parse.c |1 -
ofproto/bundles.c | 15 ++-
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/lib/ofp-parse.c b/lib/ofp-parse.c
index 16c7cdc..9bb46fc 100644
--- a/lib/ofp-parse.c
+++ b/lib/ofp-parse.c
@@ -22,7 +22,6 @@
#include
#include
-#include "bundle.h"
#include "byte-order.h"
#include "dynamic-string.h"
#include "learn.h"
diff --git a/ofproto/bundles.c b/ofproto/bundles.c
index a6637d9..4184a33 100644
--- a/ofproto/bundles.c
+++ b/ofproto/bundles.c
@@ -187,6 +187,8 @@ ofp_bundle_commit(struct ofconn *ofconn, uint32_t id,
uint16_t flags)
{
struct hmap *bundles;
struct ofp_bundle *bundle;
+enum ofperr error = 0;
+struct bundle_message *msg;
bundles = ofconn_get_bundles(ofconn);
bundle = ofp_bundle_find(bundles, id);
@@ -195,13 +197,16 @@ ofp_bundle_commit(struct ofconn *ofconn, uint32_t id,
uint16_t flags)
return OFPERR_OFPBFC_BAD_ID;
}
if (bundle->flags != flags) {
-ofp_bundle_remove(ofconn, bundle);
-return OFPERR_OFPBFC_BAD_FLAGS;
+error = OFPERR_OFPBFC_BAD_FLAGS;
+} else {
+LIST_FOR_EACH (msg, node, &bundle->msg_list) {
+/* XXX: actual commit */
+error = OFPERR_OFPBFC_MSG_FAILED;
+}
}
-/* XXX: actual commit */
-
-return OFPERR_OFPBFC_MSG_UNSUP;
+ofp_bundle_remove(ofconn, bundle);
+return error;
}
enum ofperr
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 5/8] bundles: Reject unbundlable messages.
Reject bundle add messages containing messages that should not be bundled.
Signed-off-by: Jarno Rajahalme
---
lib/ofp-util.c | 94
tests/ofp-print.at | 47 ++
2 files changed, 134 insertions(+), 7 deletions(-)
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index 8ee51ac..bfccc69 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -8487,6 +8487,92 @@ ofputil_encode_bundle_ctrl_reply(const struct ofp_header
*oh,
return buf;
}
+/* Return true for bundlable state change requests, false for other messages.
+ */
+static bool
+ofputil_is_bundlable(enum ofptype type)
+{
+switch (type) {
+/* Minimum required by OpenFlow 1.4. */
+case OFPTYPE_PORT_MOD:
+case OFPTYPE_FLOW_MOD:
+return true;
+
+/* Nice to have later. */
+case OFPTYPE_FLOW_MOD_TABLE_ID:
+case OFPTYPE_GROUP_MOD:
+case OFPTYPE_TABLE_MOD:
+case OFPTYPE_METER_MOD:
+case OFPTYPE_PACKET_OUT:
+
+/* Not to be bundlable. */
+case OFPTYPE_ECHO_REQUEST:
+case OFPTYPE_FEATURES_REQUEST:
+case OFPTYPE_GET_CONFIG_REQUEST:
+case OFPTYPE_SET_CONFIG:
+case OFPTYPE_BARRIER_REQUEST:
+case OFPTYPE_ROLE_REQUEST:
+case OFPTYPE_ECHO_REPLY:
+case OFPTYPE_SET_FLOW_FORMAT:
+case OFPTYPE_SET_PACKET_IN_FORMAT:
+case OFPTYPE_SET_CONTROLLER_ID:
+case OFPTYPE_FLOW_AGE:
+case OFPTYPE_FLOW_MONITOR_CANCEL:
+case OFPTYPE_SET_ASYNC_CONFIG:
+case OFPTYPE_GET_ASYNC_REQUEST:
+case OFPTYPE_DESC_STATS_REQUEST:
+case OFPTYPE_FLOW_STATS_REQUEST:
+case OFPTYPE_AGGREGATE_STATS_REQUEST:
+case OFPTYPE_TABLE_STATS_REQUEST:
+case OFPTYPE_TABLE_FEATURES_STATS_REQUEST:
+case OFPTYPE_PORT_STATS_REQUEST:
+case OFPTYPE_QUEUE_STATS_REQUEST:
+case OFPTYPE_PORT_DESC_STATS_REQUEST:
+case OFPTYPE_FLOW_MONITOR_STATS_REQUEST:
+case OFPTYPE_METER_STATS_REQUEST:
+case OFPTYPE_METER_CONFIG_STATS_REQUEST:
+case OFPTYPE_METER_FEATURES_STATS_REQUEST:
+case OFPTYPE_GROUP_STATS_REQUEST:
+case OFPTYPE_GROUP_DESC_STATS_REQUEST:
+case OFPTYPE_GROUP_FEATURES_STATS_REQUEST:
+case OFPTYPE_QUEUE_GET_CONFIG_REQUEST:
+case OFPTYPE_BUNDLE_CONTROL:
+case OFPTYPE_BUNDLE_ADD_MESSAGE:
+case OFPTYPE_HELLO:
+case OFPTYPE_ERROR:
+case OFPTYPE_FEATURES_REPLY:
+case OFPTYPE_GET_CONFIG_REPLY:
+case OFPTYPE_PACKET_IN:
+case OFPTYPE_FLOW_REMOVED:
+case OFPTYPE_PORT_STATUS:
+case OFPTYPE_BARRIER_REPLY:
+case OFPTYPE_QUEUE_GET_CONFIG_REPLY:
+case OFPTYPE_DESC_STATS_REPLY:
+case OFPTYPE_FLOW_STATS_REPLY:
+case OFPTYPE_QUEUE_STATS_REPLY:
+case OFPTYPE_PORT_STATS_REPLY:
+case OFPTYPE_TABLE_STATS_REPLY:
+case OFPTYPE_AGGREGATE_STATS_REPLY:
+case OFPTYPE_PORT_DESC_STATS_REPLY:
+case OFPTYPE_ROLE_REPLY:
+case OFPTYPE_FLOW_MONITOR_PAUSED:
+case OFPTYPE_FLOW_MONITOR_RESUMED:
+case OFPTYPE_FLOW_MONITOR_STATS_REPLY:
+case OFPTYPE_GET_ASYNC_REPLY:
+case OFPTYPE_GROUP_STATS_REPLY:
+case OFPTYPE_GROUP_DESC_STATS_REPLY:
+case OFPTYPE_GROUP_FEATURES_STATS_REPLY:
+case OFPTYPE_METER_STATS_REPLY:
+case OFPTYPE_METER_CONFIG_STATS_REPLY:
+case OFPTYPE_METER_FEATURES_STATS_REPLY:
+case OFPTYPE_TABLE_FEATURES_STATS_REPLY:
+case OFPTYPE_ROLE_STATUS:
+;
+}
+
+return false;
+}
+
enum ofperr
ofputil_decode_bundle_add(const struct ofp_header *oh,
struct ofputil_bundle_add_msg *msg)
@@ -8495,6 +8581,8 @@ ofputil_decode_bundle_add(const struct ofp_header *oh,
struct ofpbuf b;
enum ofpraw raw;
size_t inner_len;
+enum ofperr error;
+enum ofptype type;
ofpbuf_use_const(&b, oh, ntohs(oh->length));
raw = ofpraw_pull_assert(&b);
@@ -8513,6 +8601,12 @@ ofputil_decode_bundle_add(const struct ofp_header *oh,
return OFPERR_OFPBFC_MSG_BAD_XID;
}
+/* Reject unbundlable messages. */
+error = ofptype_decode(&type, msg->msg);
+if (error || !ofputil_is_bundlable(type)) {
+return OFPERR_OFPBFC_MSG_UNSUP; /* 'error' could be confusing. */
+}
+
return 0;
}
diff --git a/tests/ofp-print.at b/tests/ofp-print.at
index fb227c7..bab3a12 100644
--- a/tests/ofp-print.at
+++ b/tests/ofp-print.at
@@ -3220,16 +3220,49 @@ OFPT_BUNDLE_ADD_MESSAGE (OF1.4) (xid=0x0): ***decode
error: OFPBFC_MSG_BAD_XID**
])
AT_CLEANUP
-AT_SETUP([OFPT_BUNDLE_ADD_MESSAGE - OFPT_HELLO])
+AT_SETUP([OFPT_BUNDLE_ADD_MESSAGE - reject OFPT_HELLO])
AT_KEYWORDS([ofp-print])
AT_CHECK([ovs-ofctl ofp-print "\
-05 22 00 20 00 00 00 00 \
-00 00 00 01 00 01 00 01 02 00 00 08 00 00 00 00 \
-00 00 00 00 00 00 00 00 \
+05 22 00 20 00 00 00 00 00 00 00 01 00 00 00 01 \
+02 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 \
+"], [0], [dnl
+OFPT_BUNDLE_ADD_MESSAGE (OF1.4) (xid=0x0): ***decode error: OFPBFC_MSG_UNSUP***
+])
+AT_CLEANUP
+
+AT_SETUP([OFPT_BUNDLE_ADD_MESSAGE - FLOW_MOD])
+AT_KEYWORDS([ofp-print])
+AT_CHECK
[ovs-dev] [PATCH 6/8] ofproto: Reject slave controllers for bundle messages.
Slave controllers are rejected for flow and port mod messages, so they
should also be rejected for bundles (that require support at least for
flow and port mod messages).
Signed-off-by: Jarno Rajahalme
---
ofproto/ofproto.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index 1485fb4..44d36d5 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -6126,6 +6126,11 @@ handle_bundle_control(struct ofconn *ofconn, const
struct ofp_header *oh)
struct ofpbuf *buf;
struct ofputil_bundle_ctrl_msg reply;
+error = reject_slave_controller(ofconn);
+if (error) {
+return error;
+}
+
error = ofputil_decode_bundle_ctrl(oh, &bctrl);
if (error) {
return error;
@@ -6173,6 +6178,11 @@ handle_bundle_add(struct ofconn *ofconn, const struct
ofp_header *oh)
enum ofperr error;
struct ofputil_bundle_add_msg badd;
+error = reject_slave_controller(ofconn);
+if (error) {
+return error;
+}
+
error = ofputil_decode_bundle_add(oh, &badd);
if (error) {
return error;
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 3/8] OF1.4 bundles: Verify xids.
A switch may optionally verify that the 'xid' of an added message is
the same as the 'xid' of the bundle add message itself. Do it.
Signed-off-by: Jarno Rajahalme
---
lib/ofp-util.c |3 +++
tests/ofp-print.at | 10 ++
2 files changed, 13 insertions(+)
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index 839f56f..8ee51ac 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -8509,6 +8509,9 @@ ofputil_decode_bundle_add(const struct ofp_header *oh,
if (inner_len < sizeof(struct ofp_header) || inner_len > ofpbuf_size(&b)) {
return OFPERR_OFPBFC_MSG_BAD_LEN;
}
+if (msg->msg->xid != oh->xid) {
+return OFPERR_OFPBFC_MSG_BAD_XID;
+}
return 0;
}
diff --git a/tests/ofp-print.at b/tests/ofp-print.at
index c58ab7d..fb227c7 100644
--- a/tests/ofp-print.at
+++ b/tests/ofp-print.at
@@ -3210,6 +3210,16 @@ OFPT_BUNDLE_CONTROL (OF1.4) (xid=0x0):
])
AT_CLEANUP
+AT_SETUP([OFPT_BUNDLE_ADD_MESSAGE - verify xid])
+AT_KEYWORDS([ofp-print])
+AT_CHECK([ovs-ofctl ofp-print "\
+05 22 00 20 00 00 00 00 00 00 00 01 00 00 00 01 \
+02 00 00 08 00 00 00 01 00 00 00 00 00 00 00 00 \
+"], [0], [dnl
+OFPT_BUNDLE_ADD_MESSAGE (OF1.4) (xid=0x0): ***decode error:
OFPBFC_MSG_BAD_XID***
+])
+AT_CLEANUP
+
AT_SETUP([OFPT_BUNDLE_ADD_MESSAGE - OFPT_HELLO])
AT_KEYWORDS([ofp-print])
AT_CHECK([ovs-ofctl ofp-print "\
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 4/8] bundles: Reject bundle add with bad flags.
OpenFlow 1.4 states that the switch must reject a bundle add message
whose flags are different from the ones in the bundle. Do it.
Signed-off-by: Jarno Rajahalme
---
ofproto/bundles.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/ofproto/bundles.c b/ofproto/bundles.c
index ddc74c6..a6637d9 100644
--- a/ofproto/bundles.c
+++ b/ofproto/bundles.c
@@ -1,6 +1,7 @@
/*
* Copyright (c) 2013, 2014 Alexandru Copot , with
support from IXIA.
* Copyright (c) 2013, 2014 Daniel Baluta
+ * Copyright (c) 2014 Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -237,11 +238,12 @@ ofp_bundle_add_message(struct ofconn *ofconn, struct
ofputil_bundle_add_msg *bad
bundles = ofconn_get_bundles(ofconn);
hmap_insert(bundles, &bundle->node, bundle_hash(badd->bundle_id));
-}
-
-if (bundle->state == BS_CLOSED) {
+} else if (bundle->state == BS_CLOSED) {
ofp_bundle_remove(ofconn, bundle);
return OFPERR_OFPBFC_BUNDLE_CLOSED;
+} else if (badd->flags != bundle->flags) {
+ofp_bundle_remove(ofconn, bundle);
+return OFPERR_OFPBFC_BAD_FLAGS;
}
bmsg = xmalloc(sizeof *bmsg);
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 2/8] rconn: Make OF 1.4 bundle messages 'admitted'.
Use of OF 1.4 bundle messages by a controller should indicate that the controller has decided to use the switch, hence make is_admitted_msg() return 'true' for them. Signed-off-by: Jarno Rajahalme --- lib/rconn.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/rconn.c b/lib/rconn.c index 5c28806..b6ced90 100644 --- a/lib/rconn.c +++ b/lib/rconn.c @@ -1389,8 +1389,6 @@ is_admitted_msg(const struct ofpbuf *b) case OFPTYPE_GROUP_FEATURES_STATS_REPLY: case OFPTYPE_TABLE_FEATURES_STATS_REQUEST: case OFPTYPE_TABLE_FEATURES_STATS_REPLY: -case OFPTYPE_BUNDLE_CONTROL: -case OFPTYPE_BUNDLE_ADD_MESSAGE: return false; case OFPTYPE_PACKET_IN: @@ -1438,6 +1436,8 @@ is_admitted_msg(const struct ofpbuf *b) case OFPTYPE_FLOW_MONITOR_CANCEL: case OFPTYPE_FLOW_MONITOR_PAUSED: case OFPTYPE_FLOW_MONITOR_RESUMED: +case OFPTYPE_BUNDLE_CONTROL: +case OFPTYPE_BUNDLE_ADD_MESSAGE: default: return true; } -- 1.7.10.4 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 8/8] bundles: Validate bundled messages.
OpenFlow bundle messages should be decoded and validated at the time
they are added to the bundle. This commit does this for flow mod and
port mod messages.
Signed-off-by: Jarno Rajahalme
---
lib/ofp-print.c |2 +-
lib/ofp-util.c| 10 +++---
lib/ofp-util.h|5 -
ofproto/bundles.c | 34 +-
ofproto/bundles.h | 48
ofproto/ofproto.c | 35 +--
6 files changed, 98 insertions(+), 36 deletions(-)
diff --git a/lib/ofp-print.c b/lib/ofp-print.c
index c446770..18ad4b4 100644
--- a/lib/ofp-print.c
+++ b/lib/ofp-print.c
@@ -2620,7 +2620,7 @@ ofp_print_bundle_add(struct ds *s, const struct
ofp_header *oh, int verbosity)
struct ofputil_bundle_add_msg badd;
char *msg;
-error = ofputil_decode_bundle_add(oh, &badd);
+error = ofputil_decode_bundle_add(oh, &badd, NULL);
if (error) {
ofp_print_error(s, error);
return;
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index bfccc69..844c64d 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -8575,7 +8575,8 @@ ofputil_is_bundlable(enum ofptype type)
enum ofperr
ofputil_decode_bundle_add(const struct ofp_header *oh,
- struct ofputil_bundle_add_msg *msg)
+ struct ofputil_bundle_add_msg *msg,
+ enum ofptype *type_ptr)
{
const struct ofp14_bundle_ctrl_msg *m;
struct ofpbuf b;
@@ -8602,8 +8603,11 @@ ofputil_decode_bundle_add(const struct ofp_header *oh,
}
/* Reject unbundlable messages. */
-error = ofptype_decode(&type, msg->msg);
-if (error || !ofputil_is_bundlable(type)) {
+if (!type_ptr) {
+type_ptr = &type;
+}
+error = ofptype_decode(type_ptr, msg->msg);
+if (error || !ofputil_is_bundlable(*type_ptr)) {
return OFPERR_OFPBFC_MSG_UNSUP; /* 'error' could be confusing. */
}
diff --git a/lib/ofp-util.h b/lib/ofp-util.h
index 6fe2883..b486d3e 100644
--- a/lib/ofp-util.h
+++ b/lib/ofp-util.h
@@ -1093,6 +1093,8 @@ struct ofputil_bundle_add_msg {
const struct ofp_header *msg;
};
+enum ofptype;
+
enum ofperr ofputil_decode_bundle_ctrl(const struct ofp_header *,
struct ofputil_bundle_ctrl_msg *);
@@ -1103,5 +1105,6 @@ struct ofpbuf *ofputil_encode_bundle_add(enum ofp_version
ofp_version,
struct ofputil_bundle_add_msg *msg);
enum ofperr ofputil_decode_bundle_add(const struct ofp_header *,
- struct ofputil_bundle_add_msg *);
+ struct ofputil_bundle_add_msg *,
+ enum ofptype *type);
#endif /* ofp-util.h */
diff --git a/ofproto/bundles.c b/ofproto/bundles.c
index 4184a33..1d57190 100644
--- a/ofproto/bundles.c
+++ b/ofproto/bundles.c
@@ -57,11 +57,6 @@ struct ofp_bundle {
struct list msg_list;
};
-struct bundle_message {
-struct ofp_header *msg;
-struct list node; /* Element in 'struct ofp_bundles's msg_list */
-};
-
static uint32_t
bundle_hash(uint32_t id)
{
@@ -98,21 +93,20 @@ ofp_bundle_create(uint32_t id, uint16_t flags)
}
static void
-ofp_bundle_remove(struct ofconn *ofconn, struct ofp_bundle *item)
+ofp_bundle_remove(struct ofconn *ofconn, struct ofp_bundle *bundle)
{
-struct bundle_message *msg, *next;
+struct ofp_bundle_entry *msg, *next;
struct hmap *bundles;
-LIST_FOR_EACH_SAFE (msg, next, node, &item->msg_list) {
+LIST_FOR_EACH_SAFE (msg, next, node, &bundle->msg_list) {
list_remove(&msg->node);
-free(msg->msg);
-free(msg);
+ofp_bundle_entry_free(msg);
}
bundles = ofconn_get_bundles(ofconn);
-hmap_remove(bundles, &item->node);
+hmap_remove(bundles, &bundle->node);
-free(item);
+free(bundle);
}
void
@@ -188,7 +182,7 @@ ofp_bundle_commit(struct ofconn *ofconn, uint32_t id,
uint16_t flags)
struct hmap *bundles;
struct ofp_bundle *bundle;
enum ofperr error = 0;
-struct bundle_message *msg;
+struct ofp_bundle_entry *msg;
bundles = ofconn_get_bundles(ofconn);
bundle = ofp_bundle_find(bundles, id);
@@ -228,31 +222,29 @@ ofp_bundle_discard(struct ofconn *ofconn, uint32_t id)
}
enum ofperr
-ofp_bundle_add_message(struct ofconn *ofconn, struct ofputil_bundle_add_msg
*badd)
+ofp_bundle_add_message(struct ofconn *ofconn, uint32_t id, uint16_t flags,
+ struct ofp_bundle_entry *bmsg)
{
struct hmap *bundles;
struct ofp_bundle *bundle;
-struct bundle_message *bmsg;
bundles = ofconn_get_bundles(ofconn);
-bundle = ofp_bundle_find(bundles, badd->bundle_id);
+bundle = ofp_bundle_find(bundles, id);
if (!bundle) {
-bundle = ofp_bundle_create(badd->bundle_id, badd->flags);
+bundle = ofp_bundle_create(id, flags);
bund
[ovs-dev] [PATCH 1/8] connmgr: Dealloc 'bundles' in ofconn_destroy().
Signed-off-by: Jarno Rajahalme --- ofproto/connmgr.c |1 + 1 file changed, 1 insertion(+) diff --git a/ofproto/connmgr.c b/ofproto/connmgr.c index 46e7431..5971c37 100644 --- a/ofproto/connmgr.c +++ b/ofproto/connmgr.c @@ -1281,6 +1281,7 @@ ofconn_destroy(struct ofconn *ofconn) } ofp_bundle_remove_all(ofconn); +hmap_destroy(&ofconn->bundles); hmap_destroy(&ofconn->monitors); list_remove(&ofconn->node); -- 1.7.10.4 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Salut
Je m'excuse pour le dérangement, je voudrais faire votre connaissance et liée une amitié sincère avec vous, prière de me répondre. Je promets d'être honnête et de garder une bonne relation avec vous.baisers,Mlle Patricia Rosat ___ 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 Fri, Nov 14, 2014 at 07:42:09AM -0500, drfl...@avaya.com wrote: > From: Dennis Flynn > > 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, unit tests, and > news and license notice files are also updated. > > Signed-off-by: Ludovic Beliveau > Signed-off-by: Dennis Flynn Thanks for the revision and, again, sorry about the late review. I think that the code mentioned in NOTICE and debian/copyright.in in this commit was added in previous commits. Please update these files in the same patch that adds the related code. I get the following GCC warnings (it looks like you need to use "%"PRId64 instead of "%ld"): ../vswitchd/bridge.c: In function 'bridge_configure_aa': ../vswitchd/bridge.c:3787:17: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'int64_t' [-Werror=format] ../vswitchd/bridge.c:3787:17: error: format '%ld' expects argument of type 'long int', but argument 5 has type 'int64_t' [-Werror=format] ../vswitchd/bridge.c:3799:17: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'int64_t' [-Werror=format] ../vswitchd/bridge.c:3799:17: error: format '%ld' expects argument of type 'long int', but argument 5 has type 'int64_t' [-Werror=format] In ovs-vsctl.8.in, the fragment "Auto Attach configuration." seems out of place here: +These commands manage the Auto Attach I-SID/VLAN mappings. Auto Attach +configuration. The IETF Auto-Attach SPBM draft standard describes a compact +method of using IEEE 802.1AB Link Layer Discovery Protocol (LLDP) together with A lot of indentation looks out of place in ovs-vsctl.c; it looks like tabs are used on some lines (all indentation in OVS should be with spaces only). I look forward to v3 of this series. It looks like the remaining needed changes are fairly minor ones. (I'll be out of town Dec. 13-23, so if you want reviews during that time you'll have to ask someone else for them.) Thanks, Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Possible debug improvement in datapath/actions.c (do_output)
Looking at do_output, it appears that we silently drop a packet if a bad
out_port was specified because vport will be NULL from ovs_vport_rcu and we
just free the skb and return from thereon. Instead, an ideal behavior should
be to log this in user space via log_execute_message and also perhaps into
dmesg as a warning.
In 2.3, we had do_output return an error, but it was never propagated to
user space through do_execute_actions, but seems like fe90efd9d converted
do_output to a 'void' function. I'm thinking if we should bring back return
value of do_output and then have do_execute_actions return it to userspace.
Please suggest..
A patch on top of 2.3 should look like this:
diff --git a/datapath/actions.c b/datapath/actions.c
index ddacbc6..41b25aa 100644
--- a/datapath/actions.c
+++ b/datapath/actions.c
@@ -402,6 +402,7 @@ static int do_output(struct datapath *dp, struct sk_buff
*skb, int out_port)
vport = ovs_vport_rcu(dp, out_port);
if (unlikely(!vport)) {
kfree_skb(skb);
+ pr_warn("invalid port number specified: %d\n", out_port);
return -ENODEV;
}
@@ -584,13 +585,14 @@ static int do_execute_actions(struct datapath *dp, struct
sk_buff *skb,
int prev_port = -1;
const struct nlattr *a;
int rem;
+ int err;
for (a = attr, rem = len; rem > 0;
a = nla_next(a, &rem)) {
int err = 0;
if (prev_port != -1) {
- do_output(dp, skb_clone(skb, GFP_ATOMIC), prev_port);
+ err = do_output(dp, skb_clone(skb, GFP_ATOMIC),
prev_port);
prev_port = -1;
}
@@ -651,11 +653,11 @@ static int do_execute_actions(struct datapath *dp, struct
sk_buff *skb,
}
if (prev_port != -1)
- do_output(dp, skb, prev_port);
+ err = do_output(dp, skb, prev_port);
else
consume_skb(skb);
- return 0;
+ return err;
}
/* We limit the number of times that we pass into execute_actions()
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] revalidator: Fix access of uninitialized memory.
Commit 64bb477 "dpif: Minimize memory copy for revalidation." introduced
a bug where the corner case of ukey creation (in revalidator threads)
could result in access to uninitialized memory when deleting flows from
the datapath. This could result in OVS aborting or deadlock. Fix it.
Signed-off-by: Joe Stringer
---
ofproto/ofproto-dpif-upcall.c |1 +
1 file changed, 1 insertion(+)
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 38e1aff..5fe90ac 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -1675,6 +1675,7 @@ exit:
static void
delete_op_init__(struct ukey_op *op, const struct dpif_flow *flow)
{
+op->ukey = NULL;
op->dop.type = DPIF_OP_FLOW_DEL;
op->dop.u.flow_del.key = flow->key;
op->dop.u.flow_del.key_len = flow->key_len;
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] revalidator: Fix access of uninitialized memory.
On Mon, Dec 08, 2014 at 05:26:54PM -0800, Joe Stringer wrote: > Commit 64bb477 "dpif: Minimize memory copy for revalidation." introduced > a bug where the corner case of ukey creation (in revalidator threads) > could result in access to uninitialized memory when deleting flows from > the datapath. This could result in OVS aborting or deadlock. Fix it. > > Signed-off-by: Joe Stringer Seems obviously correct, thanks! Acked-by: Ben Pfaff ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] revalidator: Fix access of uninitialized memory.
On 8 December 2014 at 17:33, Ben Pfaff wrote: > On Mon, Dec 08, 2014 at 05:26:54PM -0800, Joe Stringer wrote: >> Commit 64bb477 "dpif: Minimize memory copy for revalidation." introduced >> a bug where the corner case of ukey creation (in revalidator threads) >> could result in access to uninitialized memory when deleting flows from >> the datapath. This could result in OVS aborting or deadlock. Fix it. >> >> Signed-off-by: Joe Stringer > > Seems obviously correct, thanks! > > Acked-by: Ben Pfaff Thanks, pushed to master. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] include/openvswitch/util: Add extern "C" { ... }.
Requested-by: Alan Shieh
Signed-off-by: Ben Pfaff
---
include/openvswitch/util.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/openvswitch/util.h b/include/openvswitch/util.h
index 58c2b59..b2b20a5 100644
--- a/include/openvswitch/util.h
+++ b/include/openvswitch/util.h
@@ -19,6 +19,10 @@
#include
+#ifdef __cplusplus
+extern "C" {
+#endif
+
void ovs_set_program_name__(const char *name, const char *version,
const char *date, const char *time);
@@ -28,4 +32,8 @@ void ovs_set_program_name__(const char *name, const char
*version,
const char *ovs_get_program_name(void);
const char *ovs_get_program_version(void);
+#ifdef __cplusplus
+}
+#endif
+
#endif
--
2.1.3
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Support for MCAST_Snooping
Hi, It is a openstack setup that we are using. To be more clear with the configuration: -> we have set *mcast_snooping_enable=true* on *br-int* of OVS on both the compute nodes. -> *mcast-snooping-flood=true *for *Patch-tun* port of br-int on both compute nodes ( so that the multicast traffic reaches the compute node 2 via br-tun). we can see that the igmp membership report is recieved on *br-int* (via br-tun) of compute node 2 ,which may be sent via vm1 or vm2( Acting as Recievers) .Flows on* br-int *of the compute nodes have "*normal*" action. An *mdb/show* on the first compute node shows that the packets have been snooped. The same is not true for the second compute node. Is there something amiss here? Regards, Neethi On Tue, Dec 9, 2014 at 1:04 AM, Flavio Leitner wrote: > On Mon, Dec 08, 2014 at 10:28:14PM +0530, Aman Kumar wrote: > > Hi all, > > > > Thanks again, because of your help it is working fine but i have a > problem > > with 2 compute nodes(each one is having different OVS), > > below is the complete scenario. > > [image: Inline image 1] > > > > Here, when receiver VM1 sends IGMP v2 reports, it reaches to OVS2 also > but > > only OVS1 is able to Snoops that but OVS2 is not able to snoop. > > So, Now my question is that does ovs snoops only to those ports which is > > connected to host? > > Can't it snoop the other port which is not connected to host but IGMP > > report is coming from there? > > here br-tun and br-int is bridges on ovs, i have enabled the snooping on > > br-int > > I am confused with your problem description. If you configured the > port as multicast flood port or if it is a multicast router port, then > the bridge will not learn any Report coming there because they are > automatically used to send multicast packets anyway. Flood ports are > configured by the admin. The mcast router port is automatically set > when a Query is received (you can check in the mdb). > > Other than that, the bridge should snoop any packet passing through it > using the action NORMAL regardless if it's connected to a host or not. > > fbl > > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] 2015年卓越工程师教育培养计划骨干教师研讨会的通知(2015年2月6-9日・珠海)
一、会议背景 2010年6月，根据人才规划纲要和教育规划纲要的部署，教育部启动实施了“卓越工程师教育培养计划”（简称“卓越计划”）。该计划是贯彻落实《国家中长期教育改革和发展规划纲要（2010-2020年）》和《国家中长期人才发展规划纲要（2010-2020年）》的重大改革项目，旨在培养造就一大批创新能力强、适应经济社会发展需要的高质量各类型工程技术人才，对促进高等教育面向社会需求培养人才、全面提高工程教育人才培养质量具有十分重要的示范和引导作用。 “卓越计划”实施三年多来，取得了积极进展。教育部组织制订了总体方案，建立了多部门协同的组织架构，出台了专门的政策措施；行业和企业大力支持，参与制订行业专业标准，共建工程实践教育中心，协同推进计划的实施；高校深化改革，积极探索，重构面向工程的课程体系，深入开展产学合作，提升教师的工程能力，推进工程教育国际化。“卓越计划”在实施的过程中遇到很多新问题，如学生进入企业如何完成企业工程实践、如何开展专业认证、学生的企业工程实践能力如何体现。为较强交流，应广大开设卓越工程计划高校的要求，由中国通信学会和卓越工程师教育培养计划建设联盟主办、中国通信学会青年工作委员会承办的2015年卓越工程师教育培养计划骨干教师研讨会将于2015年2月6日至9日在珠海南方软件园（临近北京师范大学珠海分校）召开。 二、参会对象 全国已获批卓越工程师教育专业院长、系主任和骨干教师等，国家级工程实践教育中心负责人和骨干教师等。与会代表将在会上与研讨报告专家进行深入交流探讨，共同解决在实施“卓越计划”中面对的难题，并整理和探讨卓越工程师计划的报告和总结。 更多详情请访问会议网站：http://www.ieccr.net/zhuoyue/2015/zyggyth/ ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] include/openvswitch/util: Add extern "C" { ... }.
On 12/08/14 at 07:19pm, Ben Pfaff wrote: > Requested-by: Alan Shieh > Signed-off-by: Ben Pfaff Acked-by: Thomas Graf ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] include/openvswitch/util: Add extern "C" { ... }.
On Tue, Dec 09, 2014 at 06:20:45AM +0100, Thomas Graf wrote: > On 12/08/14 at 07:19pm, Ben Pfaff wrote: > > Requested-by: Alan Shieh > > Signed-off-by: Ben Pfaff > > Acked-by: Thomas Graf Thanks! Applied. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
