On 01/15/2016 10:02 PM, Aaron Conole wrote:
A previous change moved some commonly used arguments from commandline to
the database. This change allows arbitrary eal arguments to be provided
via a new db entry 'other_config:dpdk-extra' which will tokenize the
string and add it to the argument list.
On 01/16/2016 08:23 PM, William Tu wrote:
> switch_in_pre_acl -> switch_out_pre_acl
>
> Signed-off-by: William Tu
> ---
> tutorial/OVN-Tutorial.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tutorial/OVN-Tutorial.md b/tutorial/OVN-Tutorial.md
> index 2e6a08d..1188fa
Panu Matilainen writes:
> On 01/15/2016 10:02 PM, Aaron Conole wrote:
>> A previous change moved some commonly used arguments from commandline to
>> the database. This change allows arbitrary eal arguments to be provided
>> via a new db entry 'other_config:dpdk-extra' which will tokenize the
>> st
Hi,
I would like to use the hash selection_method that OvS supports but with
OpenFlow13.
Could someone tell me the fields that are used as the input to the hash
function for OpenFlow13 in OvS?
Thanks,
Kash
___
dev mailing list
dev@openvswitch.org
http
Before this patch, physical.c build up the set of local datapaths for
its own use. I'd like to use it in another module in a later patch, so
pull it out of physical. It's now populated by the bindings module,
since that seems like a more appropriate place to do it, and it's also
done much earlier
Multiple logical ports on the same chassis that were connected to the
same physical network via localnet ports were not able to send packets
to each other. This was because ovn-controller created a single patch
port between br-int and the physical network access bridge and used it
for all localnet
Currently, configuration of DPDK parameters is done via the command line
through a --dpdk **OPTIONS** -- command line argument. This has a number of
challenges, including:
* It must be the first option passed to ovs-vswitchd
* It breaks from the way most other things are configured in OVS
* It does
Existing DPDK integration is provided by use of command line options which
must be split out and passed to librte in a special manner. However, this
forces any configuration to be passed by way of a special DPDK flag, and
interferes with ovs+dpdk packaging solutions.
This commit delays dpdk initia
The user has control over the DPDK internal lcore coremask, but this
parameter can be autofilled with a bit more intelligence. If the user
does not fill this parameter in, we use the lowest set bit in the
current task CPU affinity. Otherwise, we will reassign the current
thread to the specified lco
When the DPDK init function is called, it changes the executing thread's
CPU affinity to a single core specified in -c. This will result in the
userspace bridge configuration thread being rebound, even if that is not
the intent.
This change fixes that behavior by rebinding to the original thread
a
A previous change moved some commonly used arguments from commandline to
the database, and with it the ability to pass arbitrary arguments to
EAL. This change allows arbitrary eal arguments to be provided
via a new db entry 'other_config:dpdk-extra' which will tokenize the
string and add it to the
Marked committed patches as 'Accepted'
Marked duplicates as 'Not Applicable'
I have a patch that automates the marking above,
https://github.com/yew011/openvswitch.patchwork.mgmt/pull/1
Ben, can I merge it and do it in the weekly cron task?
Thanks,
Alex Wang,
On 17 January 2016 at 16:01, wrot
The purpose of this series is the final patch, which is important for
OVN and should also solve some problems that I've heard of in other
controllers over the years.
Ben Pfaff (41):
ofproto: Fix memory leak and memory exhaustion bugs in group_mod.
learning-switch: Use "if"s instead of "switch"
In handle_group_mod() cases where adding a group failed, nothing freed the
list of buckets, causing a leak. The same was true in every case of
modifying a group. This commit fixes the problem by changing add_group()
to never steal or free the buckets (modify_group() already acted this way)
and th
This code only cares about a very few kinds of OpenFlow messages, and it's
unlikely that it will care about new ones, so replace the "switch" by "if"
statements so that GCC won't complain about every new message.
Signed-off-by: Ben Pfaff
---
lib/learning-switch.c | 99 +--
Signed-off-by: Ben Pfaff
---
lib/ofp-util.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/ofp-util.h b/lib/ofp-util.h
index f51f9b8..f411651 100644
--- a/lib/ofp-util.h
+++ b/lib/ofp-util.h
@@ -1317,8 +1317,7 @@ void ofputil_uninit_tlv_table(struct ovs_list *mappings);
This call to ofpbuf_trim() comes from a time when the packets passed to
pinsched came directly from a dpif. For some time now that's no longer
true--now they are messages generated by ofputil_encode_packet_in(), which
generally are well sized and do not benefit from trimming.
This is not a bug fi
The structures declared in ofp-msgs.h for messages definitions should not
include an OpenFlow header (its presence is implied), but the definition of
these messages did. This commit fixes the definitions.
The visible bug was really minor here: messages of these kinds without any
TLVs would be rej
ofpbuf used to have members named 'frame' and 'l3' but now they're 'header'
and 'msg'.
Signed-off-by: Ben Pfaff
---
lib/ofp-msgs.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/lib/ofp-msgs.c b/lib/ofp-msgs.c
index 3a120e2..cb27f79 100644
--
Experimenter stats are handled by code in ofp-msgs, and this struct isn't
good for anything.
Signed-off-by: Ben Pfaff
---
include/openflow/openflow-1.2.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/openflow/openflow-1.2.h b/include/openflow/openflow-1.2.h
index 65417d6..3
Several OpenFlow 1.3+ messages use TLV-based properties that take a
common form. Until now, ofp-util has had some static functions for
dealing with properties. Because properties will start to be needed
outside of ofp-util, this commit breaks them out into a new library,
renaming them to begin wi
Until now it's been pretty hard to properly test any of the queue support,
because the dummy network device doesn't have any queues. By adding one
queue to the dummy network device (queue 0), we can get slightly higher
confidence that OVS queue support works correctly. I suppose we could do
even
Signed-off-by: Ben Pfaff
---
lib/ofp-prop.c | 98 +++--
lib/ofp-prop.h | 57
lib/ofp-util.c | 134 -
3 files changed, 160 insertions(+), 129 deletions(-)
diff --git a/lib/ofp-pr
An upcoming commit will have a need to parse actions incrementally, so this
change makes that easier to do.
Signed-off-by: Ben Pfaff
---
lib/ofp-actions.c | 20
lib/ofp-util.c| 2 ++
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/lib/ofp-actions.c b/li
The callers had some common code that could be reasonably encapsulated, so
this commit does so.
Signed-off-by: Ben Pfaff
---
lib/ofp-util.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index 58f7e23..0c0b571 10064
Without this, OFPST_QUEUE requests are formatted as:
OFPST_QUEUE request:port=LOCAL queue=5
With this commit, OFPST_QUEUE requests are formatted as:
OFPST_QUEUE request: port=LOCAL queue=5
which looks better.
Similarly for OFPT_PORT_MOD.
Signed-off-by: Ben Pfaff
---
lib/ofp-print.c|
The callers call dump_stats_transaction() for OFPST_* messages and
dump_transaction() for other messages, but the callee can easily
distinguish the two types, so this commit eliminates the difference for the
callers to simplify use.
This will be more valuable in an upcoming commit in which a singl
At first glance, OF1.4 queue properties look a lot like those for OF1.0
to OF1.3, but in fact their different padding makes them incompatible. In
addition, OF1.4 switches from using regular OpenFlow messages to request
queue properties, to using multipart messages. Thus, we really need to
use sep
These will see increasing use in upcoming commits.
Signed-off-by: Ben Pfaff
---
include/openflow/openflow-1.4.h | 27 -
include/openflow/openflow-1.5.h | 18
lib/ofp-prop.c | 126 ++-
lib/ofp-prop.h | 9 ++
lib/ofp-util.c
Upcoming commits will introduce uses of the "property" message formats,
which are used in OF1.3 and especially in OF1.4+, in Nicira extension
messages for earlier versions of OpenFlow. Thus, it's best to also
support the appropriate error codes in those versions of OpenFlow, so that
errors can be
These are all just copies of the otherwise generic ofp_prop_header or
ofp_prop_experimenter.
Signed-off-by: Ben Pfaff
---
include/openflow/openflow-1.3.h | 83 -
include/openflow/openflow-1.4.h | 45 +-
2 files changed, 1 insertion(+),
These will have users in upcoming commits. Unlike the previously
added helpers, there isn't any existing code that can immediately
use them.
Signed-off-by: Ben Pfaff
---
lib/ofp-prop.c | 116 +++--
lib/ofp-prop.h | 10 +
lib/ofpbuf.h |
OpenFlow 1.0 through 1.3 have a message OFPT_QUEUE_GET_CONFIG_REQUEST and
its corresponding reply, for fetching a description of the queues
configured on a given port. OpenFlow 1.4 changes this message to a
multipart message OFPMP_QUEUE_DESC, which Open vSwitch has not until now
implemented. This
This will have additional users in later commits.
Signed-off-by: Ben Pfaff
---
lib/ofp-prop.c | 22 ++
lib/ofp-prop.h | 1 +
lib/ofp-util.c | 20 ++--
3 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/lib/ofp-prop.c b/lib/ofp-prop.c
index 76031
The encoding and decoding of the OpenFlow and Open vSwitch async config
messages was, until now, a collection of disjoint code that had a lot of
redundancy. This commit changes it all to be driven using a single central
table.
This rewrite fixes a bug in the OF1.4+ version of the code, which unti
This seems a little better than a pair of bare arrays.
Signed-off-by: Ben Pfaff
---
include/openflow/openflow-common.h | 24 ++-
lib/ofp-print.c| 22 ++
lib/ofp-util.c | 79 +-
lib/ofp-util.h | 20 --
An upcoming commit will add another user.
Signed-off-by: Ben Pfaff
---
lib/ofp-print.c | 27 ++-
lib/ofp-util.c | 17 +
lib/ofp-util.h | 1 +
3 files changed, 20 insertions(+), 25 deletions(-)
diff --git a/lib/ofp-print.c b/lib/ofp-print.c
index 42e822
This isn't used yet but it will be in future commits.
This also looks forward to supporting Open vSwitch extensions to OAM_*,
which will be coming up soon.
Signed-off-by: Ben Pfaff
---
lib/ofp-msgs.h| 3 +++
lib/ofp-util.c| 32 +---
lib/ofp-util.h| 9 ++
We have a single function to decode all of these messages, so there's no
reason to do it two different ways for printing.
Signed-off-by: Ben Pfaff
---
lib/ofp-print.c | 117 +++---
tests/ofp-print.at| 26 +--
tests/ofproto-dpif.at |
The OF1.0 through OF1.3 "set async config" set the whole configuration,
OF1.4+ only update parts of it piecemeal, but the decoding function always
set the whole configuration. This commit fixes the problem by changing the
interface to require the caller to provide an initial state. (It would
be p
It's actually harder to parse OF1.2/OF1.3 "packet-in" messages when
ofp13_packet_in is involved than when the code just realizes that
ofp13_packet_in = ofp12_packet_in + cookie.
Signed-off-by: Ben Pfaff
---
include/openflow/openflow-1.3.h | 21 +--
lib/ofp-msgs.h | 2 +-
An upcoming commit will use this library from ofp-util instead of ofproto.
Signed-off-by: Ben Pfaff
---
lib/automake.mk | 4 +++-
{ofproto => lib}/pktbuf.c | 0
{ofproto => lib}/pktbuf.h | 0
ofproto/automake.mk | 4 +---
4 files changed, 4 insertions(+), 4 deletions(-)
rename {
I don't have any real evidence that these special cases make a difference
in real-world cases. The messages for the commits that add them are not
clear about the reasons for them. I seem to recall that they were only
tested with the dummy controller inside OVS, which isn't very good evidence
for
During translation it makes some sense to concatenate these in a single
array, but in my opinion it's conceptually better to separate them for
the recirc_state; they are not naturally the same thing.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-rid.c | 21 +
ofproto/of
Packet-in messages have been a bit of a mess. First, their abstraction
in the form of struct ofputil_packet_in has some fields that are used
in a clear way for incoming and outgoing packet-ins, and others
(packet_len, total_len, buffer_id) have have confusing meanings or
usage pattern depending on
These functions actually hash or compare recirc_state structs, so they
should be named that way; recirc_metadata is only a small subset of
recirc_state.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-rid.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/ofprot
An upcoming commit will add another kind of asynchronous message that
should be handled in the same way as packet-ins.
Signed-off-by: Ben Pfaff
---
ofproto/connmgr.c| 29
ofproto/connmgr.h| 20 +-
ofproto/fail-open.c | 28
Instead reconstruct it using the action set, since we already have the
logic to do that.
This seems a little nicer because we don't have to "trust" the metadata
as much.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-rid.h | 3 ---
ofproto/ofproto-dpif-xlate.c | 40 ++-
All of the callers of hash_words() and hash_words64() actually find it
easier to pass in the number of bytes instead of the number of 32-bit
or 64-bit words. These new functions allow the callers to be a little
simpler.
Signed-off-by: Ben Pfaff
---
lib/flow.h | 5 ++---
lib/has
An upcoming commit will make it possible to essentially serialize the
recirculation state into an OpenFlow message. For that purpose, we can't
sensibly pass a "struct ofproto *", but a randomly generated UUID works
just as well.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-rid.c | 9 +++
In my opinion, this makes better sense for the stack, because it's not
a packet or a collection of bytes, it's an array of struct mf_subvalue.
(I left it as an ofpbuf for accumulating stack entries during
translation, because the automatic reallocation and especially the stub
support there is helpf
One purpose of OpenFlow packet-in messages is to allow a controller to
interpose on the path of a packet through the flow tables. If, for
example, the controller needs to modify a packet in some way that the
switch doesn't directly support, the controller should be able to
program the switch to se
The existing functions either assumed that we were working with NXM
(instead of OXM), or they added or parsed a header before OXM headers.
These aren't needed when OXM is encapsulated inside a property, as will be
the case in an upcoming commit.
Signed-off-by: Ben Pfaff
---
lib/nx-match.c | 30 +
This will make it possible, in an upcoming commit, to construct a
recirc_state locally on the stack to pass to xlate_actions(). It would
also be possible to construct and pass a recirc_id_node on the stack, but
the translation process only uses the recirc_state anyway. The alternative
here of hav
I reposted this as the first patch in a new series:
https://patchwork.ozlabs.org/patch/569826/
Please review it there (although it hasn't changed).
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
The original message was received at Sun, 1 Jan 2006 01:58:42 +0530
from openvswitch.org [207.4.66.82]
- The following addresses had permanent fatal errors -
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
56 matches
Mail list logo
