[ovs-dev] [PATCH] daemon-windows: Add a missing header.
Without it, the build on Windows fails. Signed-off-by: Gurucharan Shetty --- lib/daemon-windows.c |1 + 1 file changed, 1 insertion(+) diff --git a/lib/daemon-windows.c b/lib/daemon-windows.c index cb205ca..04e1f1a 100644 --- a/lib/daemon-windows.c +++ b/lib/daemon-windows.c @@ -19,6 +19,7 @@ #include "daemon-private.h" #include #include +#include "ovs-thread.h" #include "poll-loop.h" #include "openvswitch/vlog.h" -- 1.7.9.5 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] daemon-windows: Add a missing header.
Acked-by: Alin Gabriel Serdean -Mesaj original- De la: dev [mailto:dev-boun...@openvswitch.org] În numele Gurucharan Shetty Trimis: Tuesday, December 16, 2014 7:00 PM Către: dev@openvswitch.org Cc: Gurucharan Shetty Subiect: [ovs-dev] [PATCH] daemon-windows: Add a missing header. Without it, the build on Windows fails. Signed-off-by: Gurucharan Shetty --- lib/daemon-windows.c |1 + 1 file changed, 1 insertion(+) diff --git a/lib/daemon-windows.c b/lib/daemon-windows.c index cb205ca..04e1f1a 100644 --- a/lib/daemon-windows.c +++ b/lib/daemon-windows.c @@ -19,6 +19,7 @@ #include "daemon-private.h" #include #include +#include "ovs-thread.h" #include "poll-loop.h" #include "openvswitch/vlog.h" -- 1.7.9.5 ___ 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] daemon-windows: Add a missing header.
On Tue, Dec 16, 2014 at 11:16 AM, Alin Serdean wrote: > Acked-by: Alin Gabriel Serdean Thank you, I applied this patch to master. > > > > -Mesaj original- > De la: dev [mailto:dev-boun...@openvswitch.org] În numele Gurucharan Shetty > Trimis: Tuesday, December 16, 2014 7:00 PM > Către: dev@openvswitch.org > Cc: Gurucharan Shetty > Subiect: [ovs-dev] [PATCH] daemon-windows: Add a missing header. > > Without it, the build on Windows fails. > > Signed-off-by: Gurucharan Shetty > --- > lib/daemon-windows.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/daemon-windows.c b/lib/daemon-windows.c index > cb205ca..04e1f1a 100644 > --- a/lib/daemon-windows.c > +++ b/lib/daemon-windows.c > @@ -19,6 +19,7 @@ > #include "daemon-private.h" > #include > #include > +#include "ovs-thread.h" > #include "poll-loop.h" > #include "openvswitch/vlog.h" > > -- > 1.7.9.5 > > ___ > 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] daemon-windows: Add a missing header.
Acked-by: Nithin Raju On Dec 16, 2014, at 9:00 AM, Gurucharan Shetty wrote: > Without it, the build on Windows fails. > > Signed-off-by: Gurucharan Shetty ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] Export OVS datapath performance counters via sFlow
Export OVS datapath performance counters via sFlow. The OVS
cache hit/miss counters and memory/CPU usage statistics have been identified
as important metrics when managing large deployments. This patch allows them
to be pushed periodically as part of the sFlow feed, and represents a more
efficient and scalable alternative to polling via ovs-dpctl(1).
It's safe to assume that the patch below was mangled by my email setup, so
I posted a github pull-request here:
https://github.com/openvswitch/ovs/pull/31
Signed-off-by: Neil McKee
---
lib/sflow.h | 34 ++-
lib/sflow_receiver.c | 20 +++
ofproto/ofproto-dpif-sflow.c | 136 +++
3 files changed, 189 insertions(+), 1 deletion(-)
diff --git a/lib/sflow.h b/lib/sflow.h
index 83c0a67..862a6de 100644
--- a/lib/sflow.h
+++ b/lib/sflow.h
@@ -543,6 +543,34 @@ typedef struct _SFLLACP_counters {
#define SFL_CTR_LACP_XDR_SIZE 56
+/* Application resource counters */
+
+typedef struct _SFLAPPResources_counters {
+uint32_t user_time; /* in milliseconds */
+uint32_t system_time; /* in milliseconds */
+uint64_t mem_used;
+uint64_t mem_max;
+uint32_t fd_open;
+uint32_t fd_max;
+uint32_t conn_open;
+uint32_t conn_max;
+} SFLAPPResources_counters;
+
+#define SFL_CTR_APP_RESOURCES_XDR_SIZE 40
+
+/* OVS datapath stats */
+
+typedef struct _SFLOVSDP_counters {
+uint32_t n_hit;
+uint32_t n_missed;
+uint32_t n_lost;
+uint32_t n_mask_hit;
+uint32_t n_flows;
+uint32_t n_masks;
+} SFLOVSDP_counters;
+
+#define SFL_CTR_OVSDP_XDR_SIZE 24
+
/* Counters data */
enum SFLCounters_type_tag {
@@ -554,7 +582,9 @@ enum SFLCounters_type_tag {
SFLCOUNTERS_VLAN = 5,
SFLCOUNTERS_LACP = 7,
SFLCOUNTERS_OPENFLOWPORT = 1004,
-SFLCOUNTERS_PORTNAME = 1005
+SFLCOUNTERS_PORTNAME = 1005,
+SFLCOUNTERS_APP_RESOURCES = 2203,
+SFLCOUNTERS_OVSDP= 2207
};
typedef union _SFLCounters_type {
@@ -566,6 +596,8 @@ typedef union _SFLCounters_type {
SFLLACP_counters lacp;
SFLOpenFlowPort ofPort;
SFLPortName portName;
+SFLAPPResources_counters appResources;
+SFLOVSDP_counters ovsdp;
} SFLCounters_type;
typedef struct _SFLCounters_sample_element {
diff --git a/lib/sflow_receiver.c b/lib/sflow_receiver.c
index aff62fe..dd515eb 100644
--- a/lib/sflow_receiver.c
+++ b/lib/sflow_receiver.c
@@ -652,6 +652,8 @@ static int computeCountersSampleSize(SFLReceiver
*receiver, SFL_COUNTERS_SAMPLE_
case SFLCOUNTERS_LACP: elemSiz = SFL_CTR_LACP_XDR_SIZE; break;
case SFLCOUNTERS_OPENFLOWPORT: elemSiz = SFL_CTR_OPENFLOWPORT_XDR_SIZE; break;
case SFLCOUNTERS_PORTNAME: elemSiz =
stringEncodingLength(&elem->counterBlock.portName.portName); break;
+ case SFLCOUNTERS_APP_RESOURCES: elemSiz =
SFL_CTR_APP_RESOURCES_XDR_SIZE; break;
+ case SFLCOUNTERS_OVSDP: elemSiz = SFL_CTR_OVSDP_XDR_SIZE; break;
default:
sflError(receiver, "unexpected counters_tag");
return -1;
@@ -774,6 +776,24 @@ int sfl_receiver_writeCountersSample(SFLReceiver
*receiver, SFL_COUNTERS_SAMPLE_
case SFLCOUNTERS_PORTNAME:
putString(receiver, &elem->counterBlock.portName.portName);
break;
+case SFLCOUNTERS_APP_RESOURCES:
+ putNet32(receiver, elem->counterBlock.appResources.user_time);
+ putNet32(receiver, elem->counterBlock.appResources.system_time);
+ putNet64(receiver, elem->counterBlock.appResources.mem_used);
+ putNet64(receiver, elem->counterBlock.appResources.mem_max);
+ putNet32(receiver, elem->counterBlock.appResources.fd_open);
+ putNet32(receiver, elem->counterBlock.appResources.fd_max);
+ putNet32(receiver, elem->counterBlock.appResources.conn_open);
+ putNet32(receiver, elem->counterBlock.appResources.conn_max);
+ break;
+case SFLCOUNTERS_OVSDP:
+ putNet32(receiver, elem->counterBlock.ovsdp.n_hit);
+ putNet32(receiver, elem->counterBlock.ovsdp.n_missed);
+ putNet32(receiver, elem->counterBlock.ovsdp.n_lost);
+ putNet32(receiver, elem->counterBlock.ovsdp.n_mask_hit);
+ putNet32(receiver, elem->counterBlock.ovsdp.n_flows);
+ putNet32(receiver, elem->counterBlock.ovsdp.n_masks);
+ break;
default:
sflError(receiver, "unexpected counters_tag");
return -1;
diff --git a/ofproto/ofproto-dpif-sflow.c b/ofproto/ofproto-dpif-sflow.c
index 271bb2c..3824ac9 100644
--- a/ofproto/ofproto-dpif-sflow.c
+++ b/ofproto/ofproto-dpif-sflow.c
@@ -18,6 +18,7 @@
#include
#include "ofproto-dpif-sflow.h"
#include
+#include
#include
#include
#include
@@ -46,6 +47,11 @@ VLOG_DEFINE_THIS_MODULE(sflow);
static struct ovs_mutex mutex;
+/* This global var is used to determine which sFlow
+ sub-agent should send the datapath counters. */
+#define SFLOW_GC_SUBID_UNCLAIMED (uint32_t)-1
+static uint32_t sflow_global_counters_subid = SFLOW_GC_SUBID_UNCLAIMED;
+
struct dpif_sflow_port {
struct hmap_node hmap_node; /* In struct dpif_sflow's "ports" hmap. */
SFLDataSource_instance dsi; /* sFlow library's
Re: [ovs-dev] [PATCH] ofproto: Fix MPLS multiple Push pop action.
LGTM,
With some comments below:
Acked-by: Jarno Rajahalme
Jarno
On Dec 15, 2014, at 12:37 PM, Pravin B Shelar wrote:
> vSwitchd does not generate correct MPLS actions for multiple
> MPLS push or pop action.
> Datapath can handle multiple push action for in single action list.
> But for after first MPLS pop it needs to recirculate packet to
> refill packet key. Following patch fixes it accordingly.
>
> Reported-by: Stefano Salsano
> Signed-off-by: Pravin B Shelar
> ---
> lib/flow.c | 11 ++---
> ofproto/ofproto-dpif-xlate.c | 24 ++--
> tests/automake.mk|1 +
> tests/mpls-xlate.at | 50 ++
> tests/odp.at |2 -
> tests/ofproto-dpif.at| 42 +-
> tests/testsuite.at |1 +
> 7 files changed, 92 insertions(+), 39 deletions(-)
> create mode 100644 tests/mpls-xlate.at
>
> diff --git a/lib/flow.c b/lib/flow.c
> index 521ee82..eb7fdf1 100644
> --- a/lib/flow.c
> +++ b/lib/flow.c
> @@ -1422,18 +1422,21 @@ flow_count_mpls_labels(const struct flow *flow,
> struct flow_wildcards *wc)
> /* dl_type is always masked. */
> if (eth_type_mpls(flow->dl_type)) {
> int i;
> -int len = FLOW_MAX_MPLS_LABELS;
> +int cnt;
>
> -for (i = 0; i < len; i++) {
> +cnt = 0;
> +for (i = 0; i < FLOW_MAX_MPLS_LABELS; i++) {
> if (wc) {
> wc->masks.mpls_lse[i] |= htonl(MPLS_BOS_MASK);
> }
> if (flow->mpls_lse[i] & htonl(MPLS_BOS_MASK)) {
> return i + 1;
> }
> +if (flow->mpls_lse[i]) {
> +cnt++;
> +}
If the intent is to skip potential explicit null labels, then this is maybe OK.
The explicit NULL label for IPv6 has the label value 2, should they be skipped
too?
> }
> -
> -return len;
> +return cnt;
> } else {
> return 0;
> }
> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> index 5a2b883..9b75df3 100644
> --- a/ofproto/ofproto-dpif-xlate.c
> +++ b/ofproto/ofproto-dpif-xlate.c
> @@ -3274,9 +3274,6 @@ compose_mpls_push_action(struct xlate_ctx *ctx, struct
> ofpact_push_mpls *mpls)
> }
> ctx->exit = true;
> return;
> -} else if (n >= ctx->xbridge->max_mpls_depth) {
> -COVERAGE_INC(xlate_actions_mpls_overflow);
> -ctx->xout->slow |= SLOW_ACTION;
So the datapath can push unlimited number of MPLS labels, even though it could
not parse them on input?
> }
>
> flow_push_mpls(flow, n, mpls->ethertype, wc);
> @@ -3290,7 +3287,7 @@ compose_mpls_pop_action(struct xlate_ctx *ctx, ovs_be16
> eth_type)
> int n = flow_count_mpls_labels(flow, wc);
>
> if (flow_pop_mpls(flow, n, eth_type, wc)) {
> -if (ctx->xbridge->enable_recirc && !eth_type_mpls(eth_type)) {
> +if (ctx->xbridge->enable_recirc) {
> ctx->was_mpls = true;
> }
> } else if (n >= FLOW_MAX_MPLS_LABELS) {
> @@ -3698,12 +3695,15 @@ xlate_action_set(struct xlate_ctx *ctx)
> }
>
> static bool
> -ofpact_needs_recirculation_after_mpls(const struct xlate_ctx *ctx,
> - const struct ofpact *a)
> +ofpact_needs_recirculation_after_mpls(const struct ofpact *a, struct
> xlate_ctx *ctx)
> {
> struct flow_wildcards *wc = &ctx->xout->wc;
> struct flow *flow = &ctx->xin->flow;
>
> +if (!ctx->was_mpls) {
> +return false;
> +}
> +
> switch (a->type) {
> case OFPACT_OUTPUT:
> case OFPACT_GROUP:
> @@ -3718,11 +3718,6 @@ ofpact_needs_recirculation_after_mpls(const struct
> xlate_ctx *ctx,
> case OFPACT_SET_TUNNEL:
> case OFPACT_SET_QUEUE:
> case OFPACT_POP_QUEUE:
> -case OFPACT_POP_MPLS:
> -case OFPACT_DEC_MPLS_TTL:
> -case OFPACT_SET_MPLS_TTL:
> -case OFPACT_SET_MPLS_TC:
> -case OFPACT_SET_MPLS_LABEL:
> case OFPACT_NOTE:
> case OFPACT_OUTPUT_REG:
> case OFPACT_EXIT:
> @@ -3733,6 +3728,11 @@ ofpact_needs_recirculation_after_mpls(const struct
> xlate_ctx *ctx,
> case OFPACT_SAMPLE:
> return false;
>
> +case OFPACT_POP_MPLS:
> +case OFPACT_DEC_MPLS_TTL:
> +case OFPACT_SET_MPLS_TTL:
> +case OFPACT_SET_MPLS_TC:
> +case OFPACT_SET_MPLS_LABEL:
> case OFPACT_SET_IPV4_SRC:
> case OFPACT_SET_IPV4_DST:
> case OFPACT_SET_IP_DSCP:
> @@ -3794,7 +3794,7 @@ do_xlate_actions(const struct ofpact *ofpacts, size_t
> ofpacts_len,
> break;
> }
>
> -if (ctx->was_mpls && ofpact_needs_recirculation_after_mpls(ctx, a)) {
> +if (ofpact_needs_recirculation_after_mpls(a, ctx)) {
> compose_recirculate_action(ctx, ofpacts, a, ofpacts_len);
> return;
> }
> diff --git a/tests/automake.mk b/tests/automake.mk
> index ccce112..894a5d9 100644
> --- a/tests/automake.mk
> +++ b/tests/automake.
[ovs-dev] [PATCH 1/2] route-table-bsd: Update vlog.h inclusion
This fixes a build failure introduced by the recent vlog change
commit e6211adce42c28453e0004c7a3e342a3d52bb97d.
("lib: Move vlog.h to ")
Signed-off-by: YAMAMOTO Takashi
---
lib/route-table-bsd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/route-table-bsd.c b/lib/route-table-bsd.c
index 709c9f3..557c0bf 100644
--- a/lib/route-table-bsd.c
+++ b/lib/route-table-bsd.c
@@ -31,7 +31,7 @@
#include "ovs-router.h"
#include "packets.h"
-#include "vlog.h"
+#include "openvswitch/vlog.h"
#include "util.h"
VLOG_DEFINE_THIS_MODULE(route_table_bsd);
--
1.9.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 2/2] route-table-bsd: Retry logic
Retry routing requests as the routing socket is unreliable.
Also, add some error checks and logs.
Signed-off-by: YAMAMOTO Takashi
---
lib/route-table-bsd.c | 60 ---
1 file changed, 52 insertions(+), 8 deletions(-)
diff --git a/lib/route-table-bsd.c b/lib/route-table-bsd.c
index 557c0bf..b5ff3cc 100644
--- a/lib/route-table-bsd.c
+++ b/lib/route-table-bsd.c
@@ -26,6 +26,8 @@
#include
#include
+#include
+#include
#include
#include
@@ -49,16 +51,21 @@ route_table_fallback_lookup(ovs_be32 ip, char name[],
ovs_be32 *gw)
struct sockaddr_in *sin;
struct sockaddr *sa;
static int seq;
-int i, len, namelen, rtsock;
+int i, namelen, rtsock;
+ssize_t len;
const pid_t pid = getpid();
bool got_ifp = false;
+unsigned int retry_count = 5; /* arbitrary */
+
+VLOG_DBG("looking route up for " IP_FMT " pid %" PRIuMAX,
+IP_ARGS(ip), (uintmax_t)pid);
rtsock = socket(PF_ROUTE, SOCK_RAW, 0);
if (rtsock < 0)
return false;
+retry:
memset(&rtmsg, 0, sizeof(rtmsg));
-
rtm->rtm_msglen = sizeof(struct rt_msghdr) + sizeof(struct sockaddr_in);
rtm->rtm_version = RTM_VERSION;
rtm->rtm_type = RTM_GET;
@@ -70,14 +77,52 @@ route_table_fallback_lookup(ovs_be32 ip, char name[],
ovs_be32 *gw)
sin->sin_family = AF_INET;
sin->sin_addr.s_addr = ip;
-if ((write(rtsock, (char *)&rtmsg, rtm->rtm_msglen)) < 0) {
+len = write(rtsock, (char *)&rtmsg, rtm->rtm_msglen);
+if (len == -1) {
+if (errno == ENOBUFS && retry_count-- > 0) {
+VLOG_INFO("Recoverable error writing to routing socket: %s",
+ ovs_strerror(errno));
+usleep(500 * 1000); /* arbitrary */
+goto retry;
+}
+VLOG_ERR("Error writing to routing socket: %s", ovs_strerror(errno));
+close(rtsock);
+return false;
+}
+if (len != rtm->rtm_msglen) {
+VLOG_ERR("Short write to routing socket");
close(rtsock);
return false;
}
-VLOG_DBG("looking route up for " IP_FMT " pid %" PRIuMAX,
-IP_ARGS(ip), (uintmax_t)pid);
do {
+struct pollfd pfd;
+int ret;
+
+memset(&pfd, 0, sizeof(pfd));
+pfd.fd = rtsock;
+pfd.events = POLLIN;
+/*
+ * The timeout value below is somehow arbitrary.
+ * It's to detect the lost of routing messages due to
+ * buffer exhaustion etc. The routing socket is not
+ * reliable.
+ */
+ret = poll(&pfd, 1, 500);
+if (ret == -1) {
+VLOG_ERR("Error polling on routing socket: %s",
+ ovs_strerror(errno));
+close(rtsock);
+return false;
+}
+if (ret == 0) {
+if (retry_count-- > 0) {
+VLOG_INFO("Timeout; resending routing message");
+goto retry;
+}
+close(rtsock);
+return false;
+}
len = read(rtsock, (char *)&rtmsg, sizeof(rtmsg));
if (len > 0) {
VLOG_DBG("got rtmsg pid %" PRIuMAX " seq %d",
@@ -86,10 +131,9 @@ route_table_fallback_lookup(ovs_be32 ip, char name[],
ovs_be32 *gw)
}
} while (len > 0 && (rtmsg.rtm.rtm_seq != seq ||
rtmsg.rtm.rtm_pid != pid));
-
close(rtsock);
-
-if (len < 0) {
+if (len == -1) {
+VLOG_ERR("Error reading from routing socket: %s", ovs_strerror(errno));
return false;
}
--
1.9.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [branch-2.3 V2] recirculation: Do not drop packet when there is no match from internal table.
hi, > Hey Yamamoto, > > >> what will happen if the receiving bridge also has a bond port? >> >> YAMAMOTO Takashi >> > > > For each 'balance-tcp' bond, it will have a unique 'recirc_id'. > > If the receiving bridge has a 'balance-tcp' bond with recirc_id=ABCD, > the bridge's internal table (Table 254) will contain flows matching on > this one 'recirc_id' and different 'dp_hash' values. > > If the flow miss does not have 'recirc_id' (i.e. recirc_id == 0), lookup > will > start from Table 0. > > If the flow miss has 'recirc_id' == ABCD, it will match one of the rules in > internal table and get output to the corresponding interface. > > If the flow miss has 'recirc_id' != ABCD, it will match the the rule in bold > below, then lookup from Table 0, continue on the pipeline until reaching > the bridge with the 'recirc_id'. > > priority=2,recirc_id=0,actions=drop > *priority=1,actions=resubmit(,0)* thank you for explanation. i have another question: what ensures that the recirculated packet reaches to the same bridge as before? esp. when the packet has been modified. YAMAMOTO Takashi > > Thanks, > Alex Wang, > ___ > 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] [branch-2.3 V2] recirculation: Do not drop packet when there is no match from internal table.
Hey Yamamoto, Justin and Ethan just raised the same question you asked, Yeah, there is an issue. If say, the vlan is set before recirc action, the recirc'ed flow will have a vlan id which could lead to totally different handling result, We will discuss further and address it, Thanks, Alex Wang, On Tue, Dec 16, 2014 at 4:16 PM, YAMAMOTO Takashi wrote: > > hi, > > > Hey Yamamoto, > > > > > >> what will happen if the receiving bridge also has a bond port? > >> > >> YAMAMOTO Takashi > >> > > > > > > For each 'balance-tcp' bond, it will have a unique 'recirc_id'. > > > > If the receiving bridge has a 'balance-tcp' bond with recirc_id=ABCD, > > the bridge's internal table (Table 254) will contain flows matching on > > this one 'recirc_id' and different 'dp_hash' values. > > > > If the flow miss does not have 'recirc_id' (i.e. recirc_id == 0), lookup > > will > > start from Table 0. > > > > If the flow miss has 'recirc_id' == ABCD, it will match one of the rules > in > > internal table and get output to the corresponding interface. > > > > If the flow miss has 'recirc_id' != ABCD, it will match the the rule in > bold > > below, then lookup from Table 0, continue on the pipeline until reaching > > the bridge with the 'recirc_id'. > > > > priority=2,recirc_id=0,actions=drop > > *priority=1,actions=resubmit(,0)* > > thank you for explanation. > > i have another question: what ensures that the recirculated packet > reaches to the same bridge as before? esp. when the packet has > been modified. > > YAMAMOTO Takashi > > > > > Thanks, > > Alex Wang, > > ___ > > 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] revalidator: Don't delete non-existent flow.
If ukey_acquire() returns ENOENT, then it is unable to locate the ukey
corresponding to the flow and the flow has disappeared since it was
dumped. Don't bother deleting the flow in this case, as it will fail.
Signed-off-by: Joe Stringer
---
ofproto/ofproto-dpif-upcall.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 89de528..f0cd4cc 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -1857,7 +1857,9 @@ revalidate(struct revalidator *revalidator)
COVERAGE_INC(upcall_ukey_contention);
} else {
log_unexpected_flow(f, error);
-delete_op_init__(&ops[n_ops++], f);
+if (error != ENOENT) {
+delete_op_init__(&ops[n_ops++], f);
+}
}
continue;
}
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [branch-2.3 V2] recirculation: Do not drop packet when there is no match from internal table.
It seems recirculation action should be scoped within the same OF-bridge. On Tue, Dec 16, 2014 at 4:43 PM, Alex Wang wrote: > Hey Yamamoto, > > Justin and Ethan just raised the same question you asked, > > Yeah, there is an issue. If say, the vlan is set before recirc action, > the recirc'ed flow will have a vlan id which could lead to totally > different handling result, > > We will discuss further and address it, > > Thanks, > Alex Wang, > > On Tue, Dec 16, 2014 at 4:16 PM, YAMAMOTO Takashi > wrote: >> >> hi, >> >> > Hey Yamamoto, >> > >> > >> >> what will happen if the receiving bridge also has a bond port? >> >> >> >> YAMAMOTO Takashi >> >> >> > >> > >> > For each 'balance-tcp' bond, it will have a unique 'recirc_id'. >> > >> > If the receiving bridge has a 'balance-tcp' bond with recirc_id=ABCD, >> > the bridge's internal table (Table 254) will contain flows matching on >> > this one 'recirc_id' and different 'dp_hash' values. >> > >> > If the flow miss does not have 'recirc_id' (i.e. recirc_id == 0), lookup >> > will >> > start from Table 0. >> > >> > If the flow miss has 'recirc_id' == ABCD, it will match one of the rules >> in >> > internal table and get output to the corresponding interface. >> > >> > If the flow miss has 'recirc_id' != ABCD, it will match the the rule in >> bold >> > below, then lookup from Table 0, continue on the pipeline until reaching >> > the bridge with the 'recirc_id'. >> > >> > priority=2,recirc_id=0,actions=drop >> > *priority=1,actions=resubmit(,0)* >> >> thank you for explanation. >> >> i have another question: what ensures that the recirculated packet >> reaches to the same bridge as before? esp. when the packet has >> been modified. >> >> YAMAMOTO Takashi >> >> > >> > Thanks, >> > Alex Wang, >> > ___ >> > dev mailing list >> > dev@openvswitch.org >> > http://openvswitch.org/mailman/listinfo/dev >> > ___ > 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] OVS DPDK support technical direction
Hi, As we know that Intel stopped its effort on OVDK and OVS DPDK support will all be in OVS upstream, and I have one question after digging OVDK and OVS DPDK architecture: - IMHO, OVS DPDK support can follow the existing "fast/slow path" model as being done in OVS linux kernel, i.e. just another fast path happening in DPDK threads, and this is pretty much the mechanism used by OVDK by extending a new kind of dpif provider. But for upstream OVS DPDK support, I can only see netdev extension, I don't know what's the reason behind, can anybody post any discussion relevant on this if any? Do we see huge benefit when every packet going through "netdev" type of data path instead of a fast/slow path fashion? or I missed anything obvious? Thanks, John ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [branch-2.3 V2] recirculation: Do not drop packet when there is no match from internal table.
probably we can assign distinct pseudo odp port numbers for each userland-only ports like patch ports and make datapath accept them eg. for match. in that way, we can associate a packet in_port corresponding to the port for the recirculating bridge, rather than of the receiving bridge. YAMAMOTO Takashi > It seems recirculation action should be scoped within the same OF-bridge. > > On Tue, Dec 16, 2014 at 4:43 PM, Alex Wang wrote: >> Hey Yamamoto, >> >> Justin and Ethan just raised the same question you asked, >> >> Yeah, there is an issue. If say, the vlan is set before recirc action, >> the recirc'ed flow will have a vlan id which could lead to totally >> different handling result, >> >> We will discuss further and address it, >> >> Thanks, >> Alex Wang, >> >> On Tue, Dec 16, 2014 at 4:16 PM, YAMAMOTO Takashi >> wrote: >>> >>> hi, >>> >>> > Hey Yamamoto, >>> > >>> > >>> >> what will happen if the receiving bridge also has a bond port? >>> >> >>> >> YAMAMOTO Takashi >>> >> >>> > >>> > >>> > For each 'balance-tcp' bond, it will have a unique 'recirc_id'. >>> > >>> > If the receiving bridge has a 'balance-tcp' bond with recirc_id=ABCD, >>> > the bridge's internal table (Table 254) will contain flows matching on >>> > this one 'recirc_id' and different 'dp_hash' values. >>> > >>> > If the flow miss does not have 'recirc_id' (i.e. recirc_id == 0), lookup >>> > will >>> > start from Table 0. >>> > >>> > If the flow miss has 'recirc_id' == ABCD, it will match one of the rules >>> in >>> > internal table and get output to the corresponding interface. >>> > >>> > If the flow miss has 'recirc_id' != ABCD, it will match the the rule in >>> bold >>> > below, then lookup from Table 0, continue on the pipeline until reaching >>> > the bridge with the 'recirc_id'. >>> > >>> > priority=2,recirc_id=0,actions=drop >>> > *priority=1,actions=resubmit(,0)* >>> >>> thank you for explanation. >>> >>> i have another question: what ensures that the recirculated packet >>> reaches to the same bridge as before? esp. when the packet has >>> been modified. >>> >>> YAMAMOTO Takashi >>> >>> > >>> > Thanks, >>> > Alex Wang, >>> > ___ >>> > dev mailing list >>> > dev@openvswitch.org >>> > http://openvswitch.org/mailman/listinfo/dev >>> >> ___ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
