Dear user dev@openvswitch.org, Mail server administrator of openvswitch.org
would like to let you know that,
We have found that your account was used to send a huge amount of spam messages
during the recent week.
Obviously, your computer had been compromised and now contains a hidden proxy
serv
Your message was undeliverable due to the following reason:
Your message could not be delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely t
I did spend quite some time looking at this code and VTEP schema. The goal
for me has been not only to review this piece only for VTEP emulator but
also to see the future viability of using this in a L3 edge device for OVN.
I feel that it may make sense to step back a bit and rethink the whole
arch
Hi,
The latest ovs code with commit id
(bdc30bfb5c02e1cc6142102423d14184e503487b) fails to run "make
check-valgrind TESTSUITEFLAGS='886' ". However, it passes without valgrind.
The error is reproducible with error message:
886: ofproto-dpif - sFlow packet sampling - LACP structures FAILED (
ofpro
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
These will see increasing use in upcoming commits.
Signed-off-by: Ben Pfaff
---
lib/ofp-prop.c | 80 ++
lib/ofp-prop.h | 7 +
lib/ofp-util.c | 42 +++---
3 files changed, 91 insertions(+), 38 deletions(-)
diff
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
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
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 f2ae9c7..96d0d63 10064
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
--
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
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|
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
Hello to all,
I am performing some performance testing using OVS with DPDK and I am
having some issues when I change the number of PMD cores that ovs uses.
The testing architecture consists of a source and sink processes, the
source allocates some packets from the memory pool at the beginning and
Currently, all of the PMD netdevs can only have the same number of
rx queues, which is specified in other_config:n-dpdk-rxqs.
Fix that by introducing of new option for PMD interfaces: 'n_rxq', which
specifies the maximum number of rx queues to be created for this
interface.
Example:
ovs-v
Add tunnel key to Physical_Locator to support different
tunnel ID on different locators on the same logical switch.
---
vtep/vtep.ovsschema | 7 ---
vtep/vtep.xml | 22 --
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/vtep/vtep.ovsschema b/vtep
96
You will be able to give her a good Ram Job even after 10 beers!
p{margin:10px 0;padding:0;}
table{border-collapse:collapse;}
h1,h2,h3,h4,h5,h6{display:block;margin:0;padding:0;}
img,a img{border:0;height:auto;outline:none;text-decoration:none;}
body,#bodyTable,#bodyCell{height:1
17 matches
Mail list logo
