It isn't otherwise useful and in fact hurts performance so it's disabled
without --enable-dummy.
An upcoming commit will make use of this.
Signed-off-by: Ben Pfaff
---
lib/dummy.c | 1 +
lib/dummy.h | 1 +
lib/ofp-actions.c| 61 +++
Before this commit, mirroring state was not preserved across recirculation,
which could result in a packet being mirrored to the same destination both
before and after recirculation. This commit fixes the problem and adds a
test to avoid regression.
Found by inspection.
Signed-off-by: Ben Pfaff
This makes it possible to understand what happens recirculation-wise in
translation.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xl
This seems to be a little clearer to me.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 2c9092d..be0fd13 100644
--- a/ofproto/ofproto-dpif-x
Until now, mirroring has been implemented by accumulating, across the whole
translation process, a set of mirrors that should receive a mirrored
packet. After translation was complete, mirroring restored the original
version of the packet and sent that version to the mirrors.
That implementation
Packets should never be received on mirror output ports. We drop them
when we do receive them. But by putting them through the processing that
we did until now, we made it possible for MAC learning, etc. to happen
based on these packets. This commit drops them earlier to prevent that.
Found by
This greatly reduces the number of arguments to many of the functions
involved in recirculation, which to my eye makes the code clearer. It
will also make it easier to add new recirculation state in an upcoming
commit.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-rid.c | 162
This member is used internally during translation but none of the callers
used as an output of translation.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 35 ++-
ofproto/ofproto-dpif-xlate.h | 1 -
2 files changed, 18 insertions(+), 18 deletions(-)
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 3430a57..6bad7f9 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -4784,7
The initialization of 'base_flow' was previously split into a few pieces,
and I think it's easier to understand if it's all in one place.
This also moves and rewrites the comment describing 'base_flow'. I think
that the perspective of the new comment is a little more useful.
Signed-off-by: Ben P
Nothing used them.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 7 ---
ofproto/ofproto-dpif-xlate.h | 3 ---
2 files changed, 10 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 2a91cfc..ac7ded7 100644
--- a/ofproto/ofproto-dpif-xlat
This is only used in one place and action processing can't change the
result, so only calculate it where it's needed.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dp
It seems to me that tnl_xlate_init() has two almost-separate tasks. First,
it marks most of the 'wc' bits for tunnels. Second, it checks and updates
ECN bits. This commit breaks tnl_xlate_init() into two separate functions,
one for each of those tasks.
Signed-off-by: Ben Pfaff
---
ofproto/ofp
This variable was only used as a temporary within a small scope, so it
worked just as well to just use ctx.rule there instead.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/ofproto/ofproto-dpif-xl
This takes advantage of common properties of the invocation of this
function in both callers (both supply the same 'flow' and 'packet',
although they write it differently) and avoids the need for a local
variable in each place.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 42 +
I think that this makes xlate_actions() easier to read.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 102 ---
1 file changed, 58 insertions(+), 44 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 8
Nothing outside of ofproto-dpif-xlate.c referenced this member.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 21 +++--
ofproto/ofproto-dpif-xlate.h | 1 -
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofpro
This code was a twisty maze of tiny functions, but what it actually needed
to do was simple. This makes it look that simple.
Among more stylistic changes, this removes 'user_cookie_offset' from
xlate_ctx. This member was used to communicate between two sections of
code that are both in xlate_act
It's always the size of 'odp_actions' following adding the sample actions.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 6bad7f9..e69605e 100644
Until now, struct xlate_out has embedded an ofpbuf for actions and a large
stub for it, which xlate_actions() filled in during the flow translation
process This commit removes the embedded ofpbuf and stub, instead putting a
pointer to an ofpbuf into struct xlate_in, for a caller to fill in with a
p
As I see it, this has two benefits. First, by using an initializer
rather than a series of assignment statements, the reader can be
assured that everything in the structure is actually initialized.
Second, previously the initialization of 'ctx' was scattered in
a few places in this function, which
This moves the calculation of 'ofpacts' closer to its actual use, which
in my opinion makes the code easier to read.
This commit also expands the circumstances in which OVS omits sending
NetFlow records from those where there is exactly one OpenFlow action that
sends to controller, to those where
Until now, struct xlate_out has embedded a struct flow_wildcards, which
xlate_actions() filled in during the flow translation process (unless this
was disabled with xin->skip_wildcards to in theory save time). This commit
removes the embedded flow_wildcards and 'skip_wildcards', instead putting
a
To be used in an upcoming commit.
Signed-off-by: Ben Pfaff
---
lib/ofpbuf.h | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/lib/ofpbuf.h b/lib/ofpbuf.h
index b30cbdb..9e82de2 100644
--- a/lib/ofpbuf.h
+++ b/lib/ofpbuf.h
@@ -1,5 +1,5 @@
/*
- * Copyright
To be used in an upcoming commit.
Signed-off-by: Ben Pfaff
---
lib/list.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/list.h b/lib/list.h
index 7ba1e35..c1b0891 100644
--- a/lib/list.h
+++ b/lib/list.h
@@ -23,6 +23,11 @@
#include "util.h"
#include "openvswitch
To my mind, this is a good way to ensure that '*xout' gets initialized
properly in every execution. By using an initializer rather than a
series of assignment statements, we can be assured that every member
gets initialized.
This commit makes xlate_actions() more expensive because struct
xlate_ou
For testing OVN, I wanted to make what I thought would be straightforward
changes to ofproto-dpif-xlate, but I found that it was too obscure. This
series refactors it in several minor ways that in my opinion make it
easier to understand.
A few of the patches may improve performance (e.g. patch 5)
From: Thomas Graf
Date: Wed, 29 Jul 2015 13:52:06 +0200
> This readds the config option CONFIG_OPENVSWITCH_VXLAN to avoid a
> hard dependency of OVS on VXLAN. It moves the VXLAN config compat
> code to vport-vxlan.c and allows compliation as a module.
>
> Fixes: 614732eaa12d ("openvswitch: Use r
The kernel implementation of Geneve options stores the TLV option
data in the flow exactly as received, without any further parsing.
This is then translated to known options for the purposes of matching
on flow setup (which will then install a datapath flow in the form
the kernel is expecting).
Th
On Tue, Jul 14, 2015 at 12:40 PM, Ben Pfaff wrote:
> On Tue, Jul 07, 2015 at 10:30:05PM -0700, Jesse Gross wrote:
> Here's a comment for struct tun_metadata with a little more detail, to
> try to make sure I understand it correctly:
>
> /* Tunnel option data, plus metadata to aid in their interpre
If ofproto-dpif installs a flow into the userspace datapath that doesn't
include a mask, we need to synthesize an exact match one. This is currently
done using the metaflow infrastructure, iterating over each field and
setting it to all ones.
There is a conceptual mismatch here because metaflow is
We recently came across a case where ovs trips due to a bad function pointer
because of a possible corruption in ovs rcu cbset. This typically happens if
we have 100+ VMs with ~1000 flows.
(gdb) p *cbset
$16 = {list_node = {prev = 0x7f69c0e77b70, next = 0x208f730}, cbs = {{
function = 0
We already queue the removal of the kernel module in OVS_VSWITCHD_START,
via an ON_EXIT() call. This redundant removal also doesn't interact very
well with usage of vports: If the datapath still exists in the kernel,
we cannot remove a vport module; if we cannot remove a vport module, we
cannot rem
The initial sanity test only checked IPv4 without IP fragments. This patch
adds additional tests using IPv6 and VLANs with IP fragments and expands
the existing test to be more strict.
Signed-off-by: Joe Stringer
CC: Daniele Di Proietto
---
Daniele, these tests are basic sanity checks to ensure
Signed-off-by: Joe Stringer
---
tests/kmod-macros.at | 20
tests/kmod-traffic.at | 49 +
2 files changed, 69 insertions(+)
diff --git a/tests/kmod-macros.at b/tests/kmod-macros.at
index 3487c67..be3c123 100644
--- a/tests/kmod
Hi,
Hope this email finds you well!
Would you be interested in reaching out to " New Home Owners Email List
"with opt-in verified contact information?
We maintain contacts with complete details like Contact Name(First & Last
Name), Mailing Address, IP Address, List type, Source a
(+DPDK dev team )
Hello ,
I am trying to test the OVS_DPDK performance and found that lot of packets
being treated as error packets .
ovs-vsctl get Interface dpdk0 statistics
{collisions=0, rx_bytes=38915076374, rx_crc_err=0, rx_dropped=0,
*rx_errors=3840287219
<3840287219>, *rx_frame_err=0, rx
>
> > However, there is a bit of a problem with this model as it currently
> > stands which is kind of independent of this patch and was suggested by
> > Daniel above. Freeing mbufs in the guest may cause packet corruption.
> > This was an issue with DPDK (I think it still is). When returning an
>
Hello ,
I am trying to test the OVS_DPDK performance and found that lot of packets
being treated as error packets .
ovs-vsctl get Interface dpdk0 statistics
{collisions=0, rx_bytes=38915076374, rx_crc_err=0, rx_dropped=0,
*rx_errors=3840287219,
*rx_frame_err=0, rx_over_err=0, rx_packets=292972799
Sorry for taking so long to get to this. The one question I have is:
Is OVS the right layer to be fixing this? Isn't this really an issue
of DPDK reporting a number of available queues that for practical
purposes is wrong? I.E. Shouldn't this be fixed by the DPDK driver of
this system? This pat
On 07/29/15 at 12:05pm, Pravin Shelar wrote:
> On Wed, Jul 29, 2015 at 4:52 AM, Thomas Graf wrote:
> > This readds the config option CONFIG_OPENVSWITCH_VXLAN to avoid a
> > hard dependency of OVS on VXLAN. It moves the VXLAN config compat
> > code to vport-vxlan.c and allows compliation as a modul
Signed-off-by: Joe Stringer
---
datapath/actions.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/datapath/actions.c b/datapath/actions.c
index 6e32c00..41e30e3 100644
--- a/datapath/actions.c
+++ b/datapath/actions.c
@@ -168,10 +168,7 @@ static int pop_mpls(struct sk_buf
Signed-off-by: Joe Stringer
---
.travis.yml | 1 +
acinclude.m4 | 4 ++--
datapath/datapath.h | 9 ---
datapath/flow.c | 4 +++-
datapath/linux/compat
Backport of upstream commit 2c7a88c252bf3381958cf716f31b6b2e0f2f3fa7:
"etherdev: Fix sparse error, make test usable by other functions"
Signed-off-by: Joe Stringer
---
datapath/linux/compat/include/linux/etherdevice.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/datapath/li
This series addresses a few low-hanging fruit of stylistic differences between
the ovs tree datapath module and the upstream linux module, and adds support
for Linux 4.1.
Alexander Duyck (1):
datapath: Use eth_proto_is_802_3.
Joe Stringer (5):
datapath: Whitespace fixes.
datapath: Constify
From: Alexander Duyck
Replace "ntohs(proto) >= ETH_P_802_3_MIN" w/ eth_proto_is_802_3(proto).
Backport of upstream commit 6713fc9b8fa33444aa000f0f31076f6a859ccb34:
"openvswitch: Use eth_proto_is_802_3"
Signed-off-by: Alexander Duyck
Signed-off-by: David S. Miller
Signed-off-by: Joe Stringer
Signed-off-by: Joe Stringer
---
datapath/datapath.c | 25 +
datapath/datapath.h | 2 +-
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/datapath/datapath.c b/datapath/datapath.c
index ddcd1e5..13b2696 100644
--- a/datapath/datapath.c
+++ b/datapath/datapa
Signed-off-by: Joe Stringer
---
datapath/actions.c | 6 +-
datapath/datapath.c | 2 ++
datapath/flow.h | 1 -
datapath/flow_netlink.c | 7 ---
datapath/vport.c| 3 +--
datapath/vport.h| 1 -
6 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/d
On Wed, Jul 29, 2015 at 4:52 AM, Thomas Graf wrote:
> This readds the config option CONFIG_OPENVSWITCH_VXLAN to avoid a
> hard dependency of OVS on VXLAN. It moves the VXLAN config compat
> code to vport-vxlan.c and allows compliation as a module.
>
> Fixes: 614732eaa12d ("openvswitch: Use regular
> However, there is a bit of a problem with this model as it currently stands
> which is
> kind of independent of this patch and was suggested by Daniel above. Freeing
> mbufs in the guest may cause packet corruption. This was an issue with DPDK
> (I think
> it still is). When returning an mbuf t
On Wed, Jul 29, 2015 at 08:40:04AM -0700, Ben Pfaff wrote:
> On Tue, Jul 28, 2015 at 10:32:50PM -0300, Flavio Leitner wrote:
> > On Tue, Jul 28, 2015 at 03:22:46PM -0700, Ben Pfaff wrote:
> > > This is implied by the list of ports that are valid for output in the
> > > various versions of the OpenF
>
> This is interesting, thanks for the patch.
>
> I'm definitely not a IVSHMEM expert, but I have a concern: what happens if
> the secondary OVS process allocates or frees some mbufs? (e.g because a
> packet is sent to multiple destinations or is
> dropped)
>
> I found this in the DPDK document
On Wed, Jul 29, 2015 at 12:56:51PM -0300, Flavio Leitner wrote:
> On Tue, Jul 28, 2015 at 10:05:07PM -0700, Ben Pfaff wrote:
> > Until now, OVS has parsed all OF1.1+ group buckets that lack a weight
> > as having weight 1. Unfortunately, OpenFlow says that only "select"
> > groups may have a nonze
Thx, all look good to me~
On Wed, Jul 29, 2015 at 9:02 AM, Ben Pfaff wrote:
> On Tue, Jul 28, 2015 at 05:48:50PM -0700, Alex Wang wrote:
> > On Tue, Jul 28, 2015 at 4:40 PM, Justin Pettit
> wrote:
> > > > --- a/ovn/controller/binding.c
> > > > +++ b/ovn/controller/binding.c
> > > > @@ -91,7 +91
On Tue, Jul 28, 2015 at 11:31:48PM -0700, Alex Wang wrote:
> On Tue, Jul 28, 2015 at 8:44 AM, Ben Pfaff wrote:
>
> > This will be used in documentation for an upcoming change, to document
> > how Geneve OVN options are encoded.
> >
> > The code in this change is from a series (not yet submitted)
On Tue, Jul 28, 2015 at 05:48:50PM -0700, Alex Wang wrote:
> On Tue, Jul 28, 2015 at 4:40 PM, Justin Pettit wrote:
> > > --- a/ovn/controller/binding.c
> > > +++ b/ovn/controller/binding.c
> > > @@ -91,7 +91,9 @@ binding_run(struct controller_ctx *ctx, const struct
> > ovsrec_bridge *br_int,
> > >
On Tue, Jul 28, 2015 at 10:05:07PM -0700, Ben Pfaff wrote:
> Until now, OVS has parsed all OF1.1+ group buckets that lack a weight
> as having weight 1. Unfortunately, OpenFlow says that only "select"
> groups may have a nonzero weight, and requires reporting an error for
> other kinds of groups t
On Tue, Jul 28, 2015 at 04:40:42PM -0700, Justin Pettit wrote:
> Do you think we should print a warning (at least once) to indicate
> that the integration bridge is missing? Otherwise, it could be
> confusing to someone why nothing's happening if they typo-ed their
> bridge name.
>
> Acked-by: Ju
On Tue, Jul 28, 2015 at 04:36:29PM -0700, Justin Pettit wrote:
>
> > On Jul 28, 2015, at 8:44 AM, Ben Pfaff wrote:
> >
> > I found it otherwise difficult to see what code depended on this.
>
> It might be nice to explain that you care about the dependencies due
> to upcoming patches, since it w
On Tue, Jul 28, 2015 at 04:53:24PM -0700, Justin Pettit wrote:
>
>
> > On Jul 28, 2015, at 4:18 PM, Justin Pettit wrote:
> >
> > Acked-by: Justin Pettit
>
> I should amend my Ack. I think this introduces a problem.
>
> >
> >> On Jul 28, 2015, at 8:44 AM, Ben Pfaff wrote:
> >>
> >>
> >>
On Tue, Jul 28, 2015 at 10:32:50PM -0300, Flavio Leitner wrote:
> On Tue, Jul 28, 2015 at 03:22:46PM -0700, Ben Pfaff wrote:
> > This is implied by the list of ports that are valid for output in the
> > various versions of the OpenFlow specification.
> >
> > Found by OFTest.
>
> Looks good to me.
On Tue, Jul 28, 2015 at 10:06:04PM -0300, Flavio Leitner wrote:
> On Tue, Jul 28, 2015 at 03:21:49PM -0700, Ben Pfaff wrote:
> > The OpenFlow specification says that only role changes to slave or master
> > check the generation ID, so this is a bug fix.
> >
> > Found by OFTest.
>
> Found in OF1.5
This readds the config option CONFIG_OPENVSWITCH_VXLAN to avoid a
hard dependency of OVS on VXLAN. It moves the VXLAN config compat
code to vport-vxlan.c and allows compliation as a module.
Fixes: 614732eaa12d ("openvswitch: Use regular VXLAN net_device device")
Fixes: 2661371ace96 ("openvswitch:
Hello All,
Currently Neutron support defining few subnets (IP cidrs) on a network
(logical switch)
and connecting them to the same router (or different routers).
Currently in the NB schema, the logical switch can be connected only to one
logical
router port.
This needs to be extended so a logical
64 matches
Mail list logo
