Re: [ovs-dev] [PATCH] openvswitch: Add missing initialization in validate_and_copy_set_tun()
From: Geert Uytterhoeven
Date: Wed, 11 Feb 2015 11:23:38 +0100
> net/openvswitch/flow_netlink.c: In function ‘validate_and_copy_set_tun’:
> net/openvswitch/flow_netlink.c:1749: warning: ‘err’ may be used uninitialized
> in this function
>
> If ipv4_tun_from_nlattr() returns a different positive value than
> OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS, err will be uninitialized, and
> validate_and_copy_set_tun() may return an undefined value instead of a
> zero success indicator. Initialize err to zero to fix this.
>
> Fixes: 1dd144cf5b4b47e1 ("openvswitch: Support VXLAN Group Policy extension")
> Signed-off-by: Geert Uytterhoeven
Applied.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] ovsdb-idl
Hello all, I was wondering why "ovsdb-idl" client API code is not made as a separate independent library. Assume if someone wants to write a new client for the ovsdb-idl, how will he/she link the code to the source library? How will he/she get the get the header file definitions? Regards Sreedhar ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
Hi Ben, I don't think so - jsonrpc_run() empties the rpc output queue, freeing the ofpbufs, after their contents are sent to the stream. Thanks, Mark > -Original Message- > From: Ben Pfaff [mailto:b...@nicira.com] > Sent: Friday, February 6, 2015 8:41 PM > To: Kavanagh, Mark B > Cc: dev@openvswitch.org; Rory Sexton > Subject: Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8 > > On Fri, Feb 06, 2015 at 04:43:26PM +, Mark Kavanagh wrote: > > DPDK v1.8.0 makes significant changes to struct rte_mbuf, including > > removal of the 'pkt' and 'data' fields. The latter, formally a > > pointer, is now calculated via an offset from the start of the > > segment buffer. These fields are referenced by OVS when accessing > > the data section of an ofpbuf. > > > > The following changes are required to add support for DPDK 1.8: > > - update affected functions to use the correct rte_mbuf fields > > - remove init function from netdev-dpdk (no longer required as > > rte_eal_pci_probe is now invoked from eal_init) > > - split large amounts of data across multiple ofpbufs; with the > > removal of the mbuf's 'data' pointer, and replacement with a > > 'data_off' field, it is necessary to limit the size of data > > contained in an ofpbuf to UINT16_MAX when mbufs are used > > (data_off and data_len are both of type uint16_t). > > Were data not split across multiple ofpbufs, values larger > > than UINT16_MAX for 'data_len' and 'data_off' would result > > in wrap-around, and consequently, data corruption. Changes > > introduced in this patch prevent this from occurring. > > > > Signed-off-by: Mark Kavanagh > > Signed-off-by: Mark Gray > > Signed-off-by: Rory Sexton > > At first glance, at least, this patch introduces a memory leak into > jsonrpc_send(). > > Thanks, > > Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] docs: fix overlapping 'weak' edges in ovs-vswitchd.conf.db.5
Multiple weak edges between nodes at the same rank overlaps with each other in
a dot/graphviz diagram. The vswitchd.pic used in ovs-vswitchd.conf.db.5 suffers
this problem.
Removing "constraint=false" allows graphviz to rank the nodes using the weak
edages as well so that the nodes at the ends of a weak edge won't be at the
same rank and allows mutlple 'weak' edges to be visible.
Signed-off-by: Shu Shen ---
ovsdb/ovsdb-dot.in | 1 -
1 file changed, 1 deletion(-)
diff --git a/ovsdb/ovsdb-dot.in b/ovsdb/ovsdb-dot.in
index 006d7ed..134ce22 100755
--- a/ovsdb/ovsdb-dot.in
+++ b/ovsdb/ovsdb-dot.in
@@ -30,7 +30,6 @@ def printEdge(tableName, type, baseType, label):
options = {}
options['label'] = '"%s%s"' % (label, arity)
if baseType.ref_type == 'weak':
-options['constraint'] = 'false'
options['style'] = 'dotted'
print "\t%s -> %s [%s];" % (
tableName,
--
1.9.1
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3] docs: directly convert dot diagrams into eps for generating PDF
On Tue, Feb 10, 2015 at 03:19:18PM -0800, Shu Shen wrote: > On Fri, Feb 06, 2015 at 11:14:13PM -0800, Ben Pfaff wrote: > > On Tue, Feb 03, 2015 at 11:53:29PM -0800, Shu Shen wrote: > > > The previous workflow is to convert dot diagrams into .pic format and > > > embed into manpages; double borders and arrows were not used in dot but > > > introduced in .pic conversion; edge routing in .pic was also worse than > > > dot. > > > > > > The updated workflow specifies directly in dot diagram double > > > boarders for "root set" nodes and solid/bold styles and arrows for > > > edges. The converted .eps diagram has improved routing. The .eps diagram > > > is embedded into PDF using groff PSPIC marco package when converting the > > > manpages. PSPIC package is automatically loaded by groff when output to > > > PS/PDF. > > > > > > In addition, 'constraint=false' option is removed from weak > > > references to allow positioning of node boxes to avoid overlapping > > > between multiple edges between "Mirror" and "Port" in > > > ovs-vswitchd.conf.db. > > > > > > Signed-off-by: Shu Shen > > > > I guess this seems like a regression to me. Before, I could type "make > > sandbox" then "groffer ovs-vswitchd.conf.db" and get a nice PDF manpage > > with an E-R diagram. After, the diagram is gone. > > I looked at "groffer" script and I couldn't find a way to pass it an > external dependency (.eps files). groffer copies the manpages to a /tmp > folder and generates device files from there. Therefore, even if I > managed to have .eps files installed properly along with the man page, > they are not copied over to /tmp folders. > > The only way to make groffer work is to use embedded PIC diagram. > > The other choice is to keep embedded PIC diagram in the manpage and only > have dist-docs replace with eps files when generating PDFs - but would > this be too much a kludge to justify the benefit? > > Maybe I shall just drop the patch - and only include the fix for > overlapping multiple edges by removing "constraint=fale"? Let's start with a patch that just removes constraint=false (will you post one?), and continue to think about the rest. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] docs: update CONTRIBUTING.md
Patches that modify existing code can break expected behaviour. Flag this by testing the patch with 'make check' prior to submission. Furthermore, it is not sufficient to only test patches that add files using 'make distcheck';the compile flags for this target could change the definition of some functions (ovs_assert, for example), altering the outcome of some unit tests. Rather, it is preferable to use a combination of 'make distcheck' with 'make check' to cover all bases. Signed-off-by: Mark Kavanagh --- CONTRIBUTING.md | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 23c5410..d48924f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -27,7 +27,10 @@ In particular: Testing is also important: - - A patch that adds or deletes files should be tested with + - A patch that modifies existing code should be tested with +`make check` before submission. + + - A patch that adds or deletes files should also be tested with `make distcheck` before submission. - A patch that modifies Linux kernel code should be at least -- 1.9.3 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
Hi Ben,
It was deactivated this month, but the former owner made some contributions
towards this patch - I'll remove it from the thread going forward but will
leave it in the commit.
Thanks,
Mark
> -Original Message-
> From: Ben Pfaff [mailto:b...@nicira.com]
> Sent: Monday, February 9, 2015 4:33 PM
> To: Kavanagh, Mark B
> Cc: dev@openvswitch.org; Rory Sexton
> Subject: Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
>
> I keep getting a bounce on rory.sex...@intel.com ("550 #5.1.0 Address
> rejected."). Is that email address correct?
>
> On Mon, Feb 9, 2015 at 8:16 AM, Ben Pfaff wrote:
> > It's not the ofpbufs that are leaked. Where is 's' freed? Before your
> > patch, the data in 's' was put into an ofpbuf, and eventually freed.
> > After your patch, the data in 's' is always copied a second time, by
> > ofpbuf_clone_data(), and then the copy is put into an ofpbuf (and
> > eventually freed), but 's' itself appears to be leaked.
> >
> > On Mon, Feb 09, 2015 at 04:12:58PM +, Kavanagh, Mark B wrote:
> >> Hi Ben,
> >>
> >> I don't think so - jsonrpc_run() empties the rpc output queue, freeing the
> >> ofpbufs,
> after their contents are sent to the stream.
> >>
> >> Thanks,
> >> Mark
> >>
> >> > -Original Message-
> >> > From: Ben Pfaff [mailto:b...@nicira.com]
> >> > Sent: Friday, February 6, 2015 8:41 PM
> >> > To: Kavanagh, Mark B
> >> > Cc: dev@openvswitch.org; Rory Sexton
> >> > Subject: Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
> >> >
> >> > On Fri, Feb 06, 2015 at 04:43:26PM +, Mark Kavanagh wrote:
> >> > > DPDK v1.8.0 makes significant changes to struct rte_mbuf, including
> >> > > removal of the 'pkt' and 'data' fields. The latter, formally a
> >> > > pointer, is now calculated via an offset from the start of the
> >> > > segment buffer. These fields are referenced by OVS when accessing
> >> > > the data section of an ofpbuf.
> >> > >
> >> > > The following changes are required to add support for DPDK 1.8:
> >> > > - update affected functions to use the correct rte_mbuf fields
> >> > > - remove init function from netdev-dpdk (no longer required as
> >> > > rte_eal_pci_probe is now invoked from eal_init)
> >> > > - split large amounts of data across multiple ofpbufs; with the
> >> > > removal of the mbuf's 'data' pointer, and replacement with a
> >> > > 'data_off' field, it is necessary to limit the size of data
> >> > > contained in an ofpbuf to UINT16_MAX when mbufs are used
> >> > > (data_off and data_len are both of type uint16_t).
> >> > > Were data not split across multiple ofpbufs, values larger
> >> > > than UINT16_MAX for 'data_len' and 'data_off' would result
> >> > > in wrap-around, and consequently, data corruption. Changes
> >> > > introduced in this patch prevent this from occurring.
> >> > >
> >> > > Signed-off-by: Mark Kavanagh
> >> > > Signed-off-by: Mark Gray
> >> > > Signed-off-by: Rory Sexton
> >> >
> >> > At first glance, at least, this patch introduces a memory leak into
> >> > jsonrpc_send().
> >> >
> >> > Thanks,
> >> >
> >> > Ben.
>
>
>
> --
> "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
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] netdev-dpdk: Allow changing NON_PMD_CORE_ID for testing purpose.
On Mon, Feb 9, 2015 at 2:24 PM, Alex Wang wrote: > Pravin, > > Based on my test and Kevin's confirmation, I think it is safe to apply this > patch for now. What do you think? > If you already have done test with CONFIG_RTE_LIBRTE_MBUF_DEBUG then I am ok with the patch. Acked-by: Pravin B Shelar ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] netdev-dpdk: Allow changing NON_PMD_CORE_ID for testing purpose.
Thx everyone for the help and review, I apply the patch with following comment: diff --git a/lib/netdev-dpdk.h b/lib/netdev-dpdk.h index 9a47165..694899c 100644 --- a/lib/netdev-dpdk.h +++ b/lib/netdev-dpdk.h @@ -5,6 +5,9 @@ struct dpif_packet; +/* Reserves cpu core 0 for all non-pmd threads. Changing the value of this + * macro will allow pmd thread to be pinned on cpu core 0. This may not be + * ideal since the core may be non-isolated. */ #define NON_PMD_CORE_ID 0 On Mon, Feb 9, 2015 at 3:07 PM, Pravin Shelar wrote: > On Mon, Feb 9, 2015 at 2:24 PM, Alex Wang wrote: > > Pravin, > > > > Based on my test and Kevin's confirmation, I think it is safe to apply > this > > patch for now. What do you think? > > > > If you already have done test with CONFIG_RTE_LIBRTE_MBUF_DEBUG then I > am ok with the patch. > > Acked-by: Pravin B Shelar > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] ovs-ofctl: Implementation of eviction on the basis of Importance
From: Saloni Jain
This commit enables the eviction mechanism on the basis of importance as
per the openflow specification 1.4.
ovs-ofctl -O OpenFlow14 mod-table evict
-Enable eviction on of . Eviction adds a mechanism
enabling the switch to automatically eliminate entries of lower
importance to make space for newer entries.If want to enable eviction
on all tables, user can set the as 'ALL'.
ovs-ofctl -O OpenFlow14 mod-table noevict
-Disable eviction on of .
ovs-ofctl -O OpenFlow14 dump-tables-desc
-This command provides a way to list the current configuration
(eviction for importance) of the tables on a , which is set
using the mod-table command.
Signed-off-by: Saloni Jain
Signed-off-by: Hiteshi Kalra
---
DESIGN.md | 19 +++--
NEWS| 2 +
include/openflow/openflow-1.4.h | 10 +++
lib/learning-switch.c | 2 +
lib/ofp-msgs.h | 10 +++
lib/ofp-parse.c | 4 +
lib/ofp-print.c | 62 +-
lib/ofp-util.c | 178 +++-
lib/ofp-util.h | 28 +++
lib/rconn.c | 2 +
ofproto/ofproto-provider.h | 2 +
ofproto/ofproto.c | 158 +--
tests/ofp-print.at | 1 +
tests/ofproto.at| 105
utilities/ovs-ofctl.8.in| 25 +-
utilities/ovs-ofctl.c | 21 +
16 files changed, 608 insertions(+), 21 deletions(-)
diff --git a/DESIGN.md b/DESIGN.md
index 4d94c2d..874c0f2 100644
--- a/DESIGN.md
+++ b/DESIGN.md
@@ -277,13 +277,18 @@ The table for 1.3 is the same as the one shown above for
1.2.
OpenFlow 1.4
-
-
-OpenFlow 1.4 adds the "importance" field to flow_mods, but it does not
-explicitly specify which kinds of flow_mods set the importance.For
-consistency, Open vSwitch uses the same rule for importance as for
-idle_timeout and hard_timeout, that is, only an "ADD" flow_mod sets
-the importance. (This issue has been filed with the ONF as EXT-496.)
+---
+OpenFlow 1.4 makes these changes:
+
+ - Adds the "importance" field to flow_mods, but it does not
+explicitly specify which kinds of flow_mods set the importance.
+For consistency, Open vSwitch uses the same rule for importance
+as for idle_timeout and hard_timeout, that is, only an "ADD"
+flow_mod sets the importance. (This issue has been filed with
+the ONF as EXT-496.)
+
+ - Eviction Mechanism to automatically delete entries of lower
+importance to make space for newer entries.
OFPT_PACKET_IN
==
diff --git a/NEWS b/NEWS
index adfa1d1..cd175f8 100644
--- a/NEWS
+++ b/NEWS
@@ -33,6 +33,8 @@ Post-v2.3.0
is executed last, and only if the action set has no "output" or "group"
action.
* OpenFlow 1.4+ flow "importance" is now maintained in the flow table.
+ * OpenFlow 1.4+ table-mod flow eviction on basis of importance and
+ table-description requests are now supported.
- ovs-pki: Changed message digest algorithm from MD5 to SHA-1 because
MD5 is no longer secure and some operating systems have started to disable
it in OpenSSL.
diff --git a/include/openflow/openflow-1.4.h b/include/openflow/openflow-1.4.h
index 7631e47..c1ac227 100644
--- a/include/openflow/openflow-1.4.h
+++ b/include/openflow/openflow-1.4.h
@@ -155,6 +155,16 @@ struct ofp14_table_mod {
};
OFP_ASSERT(sizeof(struct ofp14_table_mod) == 8);
+/* Body of reply to OFPMP_TABLE_DESC request. */
+struct ofp14_table_desc {
+ovs_be16 length; /* Length is padded to 64 bits. */
+uint8_t table_id; /* Identifier of table. Lower numbered tables are
consulted first. */
+uint8_t pad[1];/* Align to 32-bits. */
+ovs_be32 config; /* Bitmap of OFPTC_* values. */
+/* Followed by 0 or more OFPTMPT14_* properties. */
+};
+OFP_ASSERT(sizeof(struct ofp14_table_desc) == 8);
+
/* ## ## */
/* ## ofp14_port_stats ## */
diff --git a/lib/learning-switch.c b/lib/learning-switch.c
index 1423ac4..27273ad 100644
--- a/lib/learning-switch.c
+++ b/lib/learning-switch.c
@@ -439,6 +439,8 @@ lswitch_process_packet(struct lswitch *sw, const struct
ofpbuf *msg)
case OFPTYPE_METER_FEATURES_STATS_REPLY:
case OFPTYPE_TABLE_FEATURES_STATS_REQUEST:
case OFPTYPE_TABLE_FEATURES_STATS_REPLY:
+case OFPTYPE_TABLE_DESC_REQUEST:
+case OFPTYPE_TABLE_DESC_REPLY:
case OFPTYPE_BUNDLE_CONTROL:
case OFPTYPE_BUNDLE_ADD_MESSAGE:
default:
diff --git a/lib/ofp-msgs.h b/lib/ofp-msgs.h
index 23c334a..d14c569 100644
--- a/lib/ofp-msgs.h
+++ b/lib/ofp-msgs.h
@@ -369,6 +369,12 @@ enum ofpraw {
/* OFPST 1.3+ (12): struct ofp13_table_features, uint8_t[8][]. */
OFPRAW_OFPST13_TABLE_FEATURES_REPLY,
+/* OFPST 1.4+ (15): void. */
+OFPRAW_OFPST14_TABLE_DESC_REQUEST,
+
Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
On Tue, Feb 10, 2015 at 2:27 AM, Kavanagh, Mark B wrote: > Hi Pravin, > > The tests fail because the amount of data that an 'mbuf-type' ofpbuf can > store is now restricted to UINT16_MAX. > > In the failed tests, the amount of data added to the ofpbuf far exceeds this > limit; resolving this shortcoming will require modifications to additional > lib functions (in particular ofpbuf_resize__), but it's not clear at this > time if this is a viable option. > We can map ofpbuf size to mbuf->pkt_len which is has 32-bit storage space. pkt_len is total length of all the segments but at this point OVS-DPDK do not support multiple segments, therefore it should have same value as data_len (which is length of current segment). Thanks, Pravin. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] openvswitch: Add missing initialization in validate_and_copy_set_tun()
net/openvswitch/flow_netlink.c: In function ‘validate_and_copy_set_tun’:
net/openvswitch/flow_netlink.c:1749: warning: ‘err’ may be used uninitialized
in this function
If ipv4_tun_from_nlattr() returns a different positive value than
OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS, err will be uninitialized, and
validate_and_copy_set_tun() may return an undefined value instead of a
zero success indicator. Initialize err to zero to fix this.
Fixes: 1dd144cf5b4b47e1 ("openvswitch: Support VXLAN Group Policy extension")
Signed-off-by: Geert Uytterhoeven
---
net/openvswitch/flow_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 993281e6278dc829..3829328c5a7648bf 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -1746,7 +1746,7 @@ static int validate_and_copy_set_tun(const struct nlattr
*attr,
struct sw_flow_key key;
struct ovs_tunnel_info *tun_info;
struct nlattr *a;
- int err, start, opts_type;
+ int err = 0, start, opts_type;
ovs_match_init(&match, &key, NULL);
opts_type = ipv4_tun_from_nlattr(nla_data(attr), &match, false, log);
--
1.9.1
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
Hi Pravin,
The tests fail because the amount of data that an 'mbuf-type' ofpbuf can store
is now restricted to UINT16_MAX.
In the failed tests, the amount of data added to the ofpbuf far exceeds this
limit; resolving this shortcoming will require modifications to additional lib
functions (in particular ofpbuf_resize__), but it's not clear at this time if
this is a viable option.
Thanks,
Mark
> -Original Message-
> From: Kavanagh, Mark B
> Sent: Monday, February 9, 2015 4:15 PM
> To: Pravin Shelar
> Cc: dev@openvswitch.org; Rory Sexton
> Subject: RE: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
>
> Hi Pravin,
>
> I checked the patch before submission using 'make distcheck', which came back
> clean -
> having run 'make check' I can now see the failures that you mentioned.
>
> I'll address these, and your comments below in the next version.
>
> Thanks,
> Mark
>
> > -Original Message-
> > From: Pravin Shelar [mailto:pshe...@nicira.com]
> > Sent: Friday, February 6, 2015 11:05 PM
> > To: Kavanagh, Mark B
> > Cc: dev@openvswitch.org; Rory Sexton
> > Subject: Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
> >
> > I am seeing 4 tests failed with following assertion failed which is
> > introduced by the patch.
> > "assertion v <= OFPBUF_DATA_MAX failed in ofpbuf_set_size()"
> >
> > I have couple of comments inline.
> >
> > On Fri, Feb 6, 2015 at 8:43 AM, Mark Kavanagh
> > wrote:
> > > DPDK v1.8.0 makes significant changes to struct rte_mbuf, including
> > > removal of the 'pkt' and 'data' fields. The latter, formally a
> > > pointer, is now calculated via an offset from the start of the
> > > segment buffer. These fields are referenced by OVS when accessing
> > > the data section of an ofpbuf.
> > >
> > > The following changes are required to add support for DPDK 1.8:
> > > - update affected functions to use the correct rte_mbuf fields
> > > - remove init function from netdev-dpdk (no longer required as
> > > rte_eal_pci_probe is now invoked from eal_init)
> > > - split large amounts of data across multiple ofpbufs; with the
> > > removal of the mbuf's 'data' pointer, and replacement with a
> > > 'data_off' field, it is necessary to limit the size of data
> > > contained in an ofpbuf to UINT16_MAX when mbufs are used
> > > (data_off and data_len are both of type uint16_t).
> > > Were data not split across multiple ofpbufs, values larger
> > > than UINT16_MAX for 'data_len' and 'data_off' would result
> > > in wrap-around, and consequently, data corruption. Changes
> > > introduced in this patch prevent this from occurring.
> > >
> > > Signed-off-by: Mark Kavanagh
> > > Signed-off-by: Mark Gray
> > > Signed-off-by: Rory Sexton
> > > ---
> > > lib/jsonrpc.c | 27 +++
> > > lib/netdev-dpdk.c | 31 +--
> > > lib/ofpbuf.c |4 +++-
> > > lib/ofpbuf.h | 35 +--
> > > lib/packet-dpif.h |4 ++--
> > > 5 files changed, 62 insertions(+), 39 deletions(-)
> >
> > Can you send one combined patch with documentations fixes that you had
> > last time.
> >
> > >
> > ...
> >
> > > diff --git a/lib/ofpbuf.h b/lib/ofpbuf.h
> > > index 4e7038d0..ef0c319 100644
> > > --- a/lib/ofpbuf.h
> > > +++ b/lib/ofpbuf.h
> > > @@ -19,6 +19,11 @@
> > >
> > > #include
> > > #include
> > > +
> > > +#ifdef DPDK_NETDEV
> > > +#include
> > > +#endif
> > > +
> > > #include "list.h"
> > > #include "packets.h"
> > > #include "util.h"
> > > @@ -28,6 +33,12 @@
> > > extern "C" {
> > > #endif
> > >
> > > +#ifdef DPDK_NETDEV
> > > +#define OFPBUF_DATA_MAX UINT16_MAX
> > > +#else
> > > +#define OFPBUF_DATA_MAX UINT32_MAX
> > > +#endif
> > > +
> > > enum OVS_PACKED_ENUM ofpbuf_source {
> > > OFPBUF_MALLOC, /* Obtained via malloc(). */
> > > OFPBUF_STACK, /* Un-movable stack space or static
> > > buffer. */
> > > @@ -386,12 +397,23 @@ BUILD_ASSERT_DECL(offsetof(struct ofpbuf, mbuf) ==
> > > 0);
> > >
> > > static inline void * ofpbuf_data(const struct ofpbuf *b)
> > > {
> > > -return b->mbuf.pkt.data;
> > > +return rte_pktmbuf_mtod(&(b->mbuf), void *);
> > > }
> > >
> > > static inline void ofpbuf_set_data(struct ofpbuf *b, void *d)
> > > {
> > > -b->mbuf.pkt.data = d;
> > > +uintptr_t data_delta;
> > > +
> > > +/* NULL 'd' value is valid */
> > > +if (unlikely(d == NULL)) {
> > > +b->mbuf.data_off = 0;
> >
> > ofpbuf_data() need to return NULL for this case.
> >
> > > +} else {
> > > +ovs_assert(d >= b->mbuf.buf_addr);
> > > +/* Work out the offset between the start of segment buffer and
> > > 'd' */
> > > +data_delta = RTE_PTR_DIFF(d, b->mbuf.buf_addr);
> > > +ovs_assert(data_delta <= OFPBUF_DATA_MAX);
> > > +b->mbuf.data_off = data_delta;
> > > +}
> > > }
> > >
___
dev mailing list
dev@openvswitch.org
http://
Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
I keep getting a bounce on rory.sex...@intel.com ("550 #5.1.0 Address
rejected."). Is that email address correct?
On Mon, Feb 9, 2015 at 8:16 AM, Ben Pfaff wrote:
> It's not the ofpbufs that are leaked. Where is 's' freed? Before your
> patch, the data in 's' was put into an ofpbuf, and eventually freed.
> After your patch, the data in 's' is always copied a second time, by
> ofpbuf_clone_data(), and then the copy is put into an ofpbuf (and
> eventually freed), but 's' itself appears to be leaked.
>
> On Mon, Feb 09, 2015 at 04:12:58PM +, Kavanagh, Mark B wrote:
>> Hi Ben,
>>
>> I don't think so - jsonrpc_run() empties the rpc output queue, freeing the
>> ofpbufs, after their contents are sent to the stream.
>>
>> Thanks,
>> Mark
>>
>> > -Original Message-
>> > From: Ben Pfaff [mailto:b...@nicira.com]
>> > Sent: Friday, February 6, 2015 8:41 PM
>> > To: Kavanagh, Mark B
>> > Cc: dev@openvswitch.org; Rory Sexton
>> > Subject: Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
>> >
>> > On Fri, Feb 06, 2015 at 04:43:26PM +, Mark Kavanagh wrote:
>> > > DPDK v1.8.0 makes significant changes to struct rte_mbuf, including
>> > > removal of the 'pkt' and 'data' fields. The latter, formally a
>> > > pointer, is now calculated via an offset from the start of the
>> > > segment buffer. These fields are referenced by OVS when accessing
>> > > the data section of an ofpbuf.
>> > >
>> > > The following changes are required to add support for DPDK 1.8:
>> > > - update affected functions to use the correct rte_mbuf fields
>> > > - remove init function from netdev-dpdk (no longer required as
>> > > rte_eal_pci_probe is now invoked from eal_init)
>> > > - split large amounts of data across multiple ofpbufs; with the
>> > > removal of the mbuf's 'data' pointer, and replacement with a
>> > > 'data_off' field, it is necessary to limit the size of data
>> > > contained in an ofpbuf to UINT16_MAX when mbufs are used
>> > > (data_off and data_len are both of type uint16_t).
>> > > Were data not split across multiple ofpbufs, values larger
>> > > than UINT16_MAX for 'data_len' and 'data_off' would result
>> > > in wrap-around, and consequently, data corruption. Changes
>> > > introduced in this patch prevent this from occurring.
>> > >
>> > > Signed-off-by: Mark Kavanagh
>> > > Signed-off-by: Mark Gray
>> > > Signed-off-by: Rory Sexton
>> >
>> > At first glance, at least, this patch introduces a memory leak into
>> > jsonrpc_send().
>> >
>> > Thanks,
>> >
>> > Ben.
--
"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
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] openvswitch: Add missing initialization in validate_and_copy_set_tun()
On Wed, Feb 11, 2015 at 2:23 AM, Geert Uytterhoeven
wrote:
> net/openvswitch/flow_netlink.c: In function ‘validate_and_copy_set_tun’:
> net/openvswitch/flow_netlink.c:1749: warning: ‘err’ may be used uninitialized
> in this function
>
> If ipv4_tun_from_nlattr() returns a different positive value than
> OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS, err will be uninitialized, and
> validate_and_copy_set_tun() may return an undefined value instead of a
> zero success indicator. Initialize err to zero to fix this.
>
> Fixes: 1dd144cf5b4b47e1 ("openvswitch: Support VXLAN Group Policy extension")
> Signed-off-by: Geert Uytterhoeven
Acked-by: Pravin B Shelar
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH v2.1] timeval: Correctly report usage statistics in log_poll_interval().
Most of the information that timeval was reporting for long poll intervals
was comparing per-thread with per-process statistics, which yielded
nonsense a lot of the time.
Signed-off-by: Ben Pfaff
---
v1->v2: Really fix the whole problem (thanks Alex!)
v2->v2.1: Repost now that the list is back up.
lib/timeval.c | 57 +++--
1 file changed, 31 insertions(+), 26 deletions(-)
diff --git a/lib/timeval.c b/lib/timeval.c
index 6173aff..a77fc61 100644
--- a/lib/timeval.c
+++ b/lib/timeval.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014 Nicira, Inc.
+ * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -102,6 +102,7 @@ DEFINE_STATIC_PER_THREAD_DATA(long long int, last_wakeup,
0);
static void log_poll_interval(long long int last_wakeup);
static struct rusage *get_recent_rusage(void);
+static int getrusage_thread(struct rusage *);
static void refresh_rusage(void);
static void timespec_add(struct timespec *sum,
const struct timespec *a, const struct timespec *b);
@@ -561,31 +562,35 @@ log_poll_interval(long long int last_wakeup)
const struct rusage *last_rusage = get_recent_rusage();
struct rusage rusage;
-getrusage(RUSAGE_SELF, &rusage);
-VLOG_WARN("Unreasonably long %lldms poll interval"
- " (%lldms user, %lldms system)",
- interval,
- timeval_diff_msec(&rusage.ru_utime,
-&last_rusage->ru_utime),
- timeval_diff_msec(&rusage.ru_stime,
-&last_rusage->ru_stime));
-if (rusage.ru_minflt > last_rusage->ru_minflt
-|| rusage.ru_majflt > last_rusage->ru_majflt) {
-VLOG_WARN("faults: %ld minor, %ld major",
- rusage.ru_minflt - last_rusage->ru_minflt,
- rusage.ru_majflt - last_rusage->ru_majflt);
-}
-if (rusage.ru_inblock > last_rusage->ru_inblock
-|| rusage.ru_oublock > last_rusage->ru_oublock) {
-VLOG_WARN("disk: %ld reads, %ld writes",
- rusage.ru_inblock - last_rusage->ru_inblock,
- rusage.ru_oublock - last_rusage->ru_oublock);
-}
-if (rusage.ru_nvcsw > last_rusage->ru_nvcsw
-|| rusage.ru_nivcsw > last_rusage->ru_nivcsw) {
-VLOG_WARN("context switches: %ld voluntary, %ld involuntary",
- rusage.ru_nvcsw - last_rusage->ru_nvcsw,
- rusage.ru_nivcsw - last_rusage->ru_nivcsw);
+if (!getrusage_thread(&rusage)) {
+VLOG_WARN("Unreasonably long %lldms poll interval"
+ " (%lldms user, %lldms system)",
+ interval,
+ timeval_diff_msec(&rusage.ru_utime,
+&last_rusage->ru_utime),
+ timeval_diff_msec(&rusage.ru_stime,
+&last_rusage->ru_stime));
+
+if (rusage.ru_minflt > last_rusage->ru_minflt
+|| rusage.ru_majflt > last_rusage->ru_majflt) {
+VLOG_WARN("faults: %ld minor, %ld major",
+ rusage.ru_minflt - last_rusage->ru_minflt,
+ rusage.ru_majflt - last_rusage->ru_majflt);
+}
+if (rusage.ru_inblock > last_rusage->ru_inblock
+|| rusage.ru_oublock > last_rusage->ru_oublock) {
+VLOG_WARN("disk: %ld reads, %ld writes",
+ rusage.ru_inblock - last_rusage->ru_inblock,
+ rusage.ru_oublock - last_rusage->ru_oublock);
+}
+if (rusage.ru_nvcsw > last_rusage->ru_nvcsw
+|| rusage.ru_nivcsw > last_rusage->ru_nivcsw) {
+VLOG_WARN("context switches: %ld voluntary, %ld involuntary",
+ rusage.ru_nvcsw - last_rusage->ru_nvcsw,
+ rusage.ru_nivcsw - last_rusage->ru_nivcsw);
+}
+} else {
+VLOG_WARN("Unreasonably long %lldms poll interval", interval);
}
coverage_log();
}
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2.1] timeval: Correctly report usage statistics in log_poll_interval().
Thx for the fix!
Acked-by: Alex Wang
On Wed, Feb 11, 2015 at 2:54 PM, Ben Pfaff wrote:
> Most of the information that timeval was reporting for long poll intervals
> was comparing per-thread with per-process statistics, which yielded
> nonsense a lot of the time.
>
> Signed-off-by: Ben Pfaff
> ---
> v1->v2: Really fix the whole problem (thanks Alex!)
> v2->v2.1: Repost now that the list is back up.
>
> lib/timeval.c | 57
> +++--
> 1 file changed, 31 insertions(+), 26 deletions(-)
>
> diff --git a/lib/timeval.c b/lib/timeval.c
> index 6173aff..a77fc61 100644
> --- a/lib/timeval.c
> +++ b/lib/timeval.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014 Nicira, Inc.
> + * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Nicira,
> Inc.
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
> @@ -102,6 +102,7 @@ DEFINE_STATIC_PER_THREAD_DATA(long long int,
> last_wakeup, 0);
>
> static void log_poll_interval(long long int last_wakeup);
> static struct rusage *get_recent_rusage(void);
> +static int getrusage_thread(struct rusage *);
> static void refresh_rusage(void);
> static void timespec_add(struct timespec *sum,
> const struct timespec *a, const struct timespec
> *b);
> @@ -561,31 +562,35 @@ log_poll_interval(long long int last_wakeup)
> const struct rusage *last_rusage = get_recent_rusage();
> struct rusage rusage;
>
> -getrusage(RUSAGE_SELF, &rusage);
> -VLOG_WARN("Unreasonably long %lldms poll interval"
> - " (%lldms user, %lldms system)",
> - interval,
> - timeval_diff_msec(&rusage.ru_utime,
> -&last_rusage->ru_utime),
> - timeval_diff_msec(&rusage.ru_stime,
> -&last_rusage->ru_stime));
> -if (rusage.ru_minflt > last_rusage->ru_minflt
> -|| rusage.ru_majflt > last_rusage->ru_majflt) {
> -VLOG_WARN("faults: %ld minor, %ld major",
> - rusage.ru_minflt - last_rusage->ru_minflt,
> - rusage.ru_majflt - last_rusage->ru_majflt);
> -}
> -if (rusage.ru_inblock > last_rusage->ru_inblock
> -|| rusage.ru_oublock > last_rusage->ru_oublock) {
> -VLOG_WARN("disk: %ld reads, %ld writes",
> - rusage.ru_inblock - last_rusage->ru_inblock,
> - rusage.ru_oublock - last_rusage->ru_oublock);
> -}
> -if (rusage.ru_nvcsw > last_rusage->ru_nvcsw
> -|| rusage.ru_nivcsw > last_rusage->ru_nivcsw) {
> -VLOG_WARN("context switches: %ld voluntary, %ld involuntary",
> - rusage.ru_nvcsw - last_rusage->ru_nvcsw,
> - rusage.ru_nivcsw - last_rusage->ru_nivcsw);
> +if (!getrusage_thread(&rusage)) {
> +VLOG_WARN("Unreasonably long %lldms poll interval"
> + " (%lldms user, %lldms system)",
> + interval,
> + timeval_diff_msec(&rusage.ru_utime,
> +&last_rusage->ru_utime),
> + timeval_diff_msec(&rusage.ru_stime,
> +&last_rusage->ru_stime));
> +
> +if (rusage.ru_minflt > last_rusage->ru_minflt
> +|| rusage.ru_majflt > last_rusage->ru_majflt) {
> +VLOG_WARN("faults: %ld minor, %ld major",
> + rusage.ru_minflt - last_rusage->ru_minflt,
> + rusage.ru_majflt - last_rusage->ru_majflt);
> +}
> +if (rusage.ru_inblock > last_rusage->ru_inblock
> +|| rusage.ru_oublock > last_rusage->ru_oublock) {
> +VLOG_WARN("disk: %ld reads, %ld writes",
> + rusage.ru_inblock - last_rusage->ru_inblock,
> + rusage.ru_oublock - last_rusage->ru_oublock);
> +}
> +if (rusage.ru_nvcsw > last_rusage->ru_nvcsw
> +|| rusage.ru_nivcsw > last_rusage->ru_nivcsw) {
> +VLOG_WARN("context switches: %ld voluntary, %ld
> involuntary",
> + rusage.ru_nvcsw - last_rusage->ru_nvcsw,
> + rusage.ru_nivcsw - last_rusage->ru_nivcsw);
> +}
> +} else {
> +VLOG_WARN("Unreasonably long %lldms poll interval", interval);
> }
> coverage_log();
> }
> --
> 1.7.10.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] [PATCH v2.1] timeval: Correctly report usage statistics in log_poll_interval().
Thanks! I applied to master and branch-2.[310].
On Wed, Feb 11, 2015 at 02:59:59PM -0800, Alex Wang wrote:
> Thx for the fix!
>
> Acked-by: Alex Wang
>
> On Wed, Feb 11, 2015 at 2:54 PM, Ben Pfaff wrote:
>
> > Most of the information that timeval was reporting for long poll intervals
> > was comparing per-thread with per-process statistics, which yielded
> > nonsense a lot of the time.
> >
> > Signed-off-by: Ben Pfaff
> > ---
> > v1->v2: Really fix the whole problem (thanks Alex!)
> > v2->v2.1: Repost now that the list is back up.
> >
> > lib/timeval.c | 57
> > +++--
> > 1 file changed, 31 insertions(+), 26 deletions(-)
> >
> > diff --git a/lib/timeval.c b/lib/timeval.c
> > index 6173aff..a77fc61 100644
> > --- a/lib/timeval.c
> > +++ b/lib/timeval.c
> > @@ -1,5 +1,5 @@
> > /*
> > - * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014 Nicira, Inc.
> > + * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Nicira,
> > Inc.
> > *
> > * Licensed under the Apache License, Version 2.0 (the "License");
> > * you may not use this file except in compliance with the License.
> > @@ -102,6 +102,7 @@ DEFINE_STATIC_PER_THREAD_DATA(long long int,
> > last_wakeup, 0);
> >
> > static void log_poll_interval(long long int last_wakeup);
> > static struct rusage *get_recent_rusage(void);
> > +static int getrusage_thread(struct rusage *);
> > static void refresh_rusage(void);
> > static void timespec_add(struct timespec *sum,
> > const struct timespec *a, const struct timespec
> > *b);
> > @@ -561,31 +562,35 @@ log_poll_interval(long long int last_wakeup)
> > const struct rusage *last_rusage = get_recent_rusage();
> > struct rusage rusage;
> >
> > -getrusage(RUSAGE_SELF, &rusage);
> > -VLOG_WARN("Unreasonably long %lldms poll interval"
> > - " (%lldms user, %lldms system)",
> > - interval,
> > - timeval_diff_msec(&rusage.ru_utime,
> > -&last_rusage->ru_utime),
> > - timeval_diff_msec(&rusage.ru_stime,
> > -&last_rusage->ru_stime));
> > -if (rusage.ru_minflt > last_rusage->ru_minflt
> > -|| rusage.ru_majflt > last_rusage->ru_majflt) {
> > -VLOG_WARN("faults: %ld minor, %ld major",
> > - rusage.ru_minflt - last_rusage->ru_minflt,
> > - rusage.ru_majflt - last_rusage->ru_majflt);
> > -}
> > -if (rusage.ru_inblock > last_rusage->ru_inblock
> > -|| rusage.ru_oublock > last_rusage->ru_oublock) {
> > -VLOG_WARN("disk: %ld reads, %ld writes",
> > - rusage.ru_inblock - last_rusage->ru_inblock,
> > - rusage.ru_oublock - last_rusage->ru_oublock);
> > -}
> > -if (rusage.ru_nvcsw > last_rusage->ru_nvcsw
> > -|| rusage.ru_nivcsw > last_rusage->ru_nivcsw) {
> > -VLOG_WARN("context switches: %ld voluntary, %ld involuntary",
> > - rusage.ru_nvcsw - last_rusage->ru_nvcsw,
> > - rusage.ru_nivcsw - last_rusage->ru_nivcsw);
> > +if (!getrusage_thread(&rusage)) {
> > +VLOG_WARN("Unreasonably long %lldms poll interval"
> > + " (%lldms user, %lldms system)",
> > + interval,
> > + timeval_diff_msec(&rusage.ru_utime,
> > +&last_rusage->ru_utime),
> > + timeval_diff_msec(&rusage.ru_stime,
> > +&last_rusage->ru_stime));
> > +
> > +if (rusage.ru_minflt > last_rusage->ru_minflt
> > +|| rusage.ru_majflt > last_rusage->ru_majflt) {
> > +VLOG_WARN("faults: %ld minor, %ld major",
> > + rusage.ru_minflt - last_rusage->ru_minflt,
> > + rusage.ru_majflt - last_rusage->ru_majflt);
> > +}
> > +if (rusage.ru_inblock > last_rusage->ru_inblock
> > +|| rusage.ru_oublock > last_rusage->ru_oublock) {
> > +VLOG_WARN("disk: %ld reads, %ld writes",
> > + rusage.ru_inblock - last_rusage->ru_inblock,
> > + rusage.ru_oublock - last_rusage->ru_oublock);
> > +}
> > +if (rusage.ru_nvcsw > last_rusage->ru_nvcsw
> > +|| rusage.ru_nivcsw > last_rusage->ru_nivcsw) {
> > +VLOG_WARN("context switches: %ld voluntary, %ld
> > involuntary",
> > + rusage.ru_nvcsw - last_rusage->ru_nvcsw,
> > + rusage.ru_nivcsw - last_rusage->ru_nivcsw);
> > +}
> > +} else {
> > +VLOG_WARN("Unreasonably long %lldms poll interval", interval);
> > }
> > coverage
Re: [ovs-dev] ovsdb-idl
Hello all, I have been wondering why doesn open-vswitch code links the entire "lib/libopenvswitch.la" into every binary in the code. Isn't that very in-efficient? Shouldn't we create separate libraries based on some logical divide, and then link the libraries based on the need. We should have created the following libraries in the source code. 1) LACP.a. 2) Sflow.a 3) Vlog.a 4) Ovsdb_client.a 5) Etc.. That will give flexibility to developers who want to create their own tools based on open-vswitch code. With the current design, a developer has to link almost the entire "lib/libopenvswitch.la" even in a small tool which uses ovsdb. Can someone through some history behind this design. If there is no specific reason, can I separate these things into small logical libraries and submit the patch? Regards Sreedhar _ From: Papudippu, Sreedhar Reddy Sent: Monday, February 09, 2015 3:10 PM To: dev@openvswitch.org Subject: ovsdb-idl Hello all, I was wondering why "ovsdb-idl" client API code is not made as a separate independent library. Assume if someone wants to write a new client for the ovsdb-idl, how will he/she link the code to the source library? How will he/she get the get the header file definitions? Regards Sreedhar ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] 国外的客户很懒，真正到B2B上找供应商的太少了
您好|| dev@openvswitch.org 您在做外贸？您的客户资源太少？解决方案如下： 国外客户主动开发方式--双喜软件 是一款外贸客户联系方式搜索软件 功能：关键词搜索网站 设置你们产品的关键词或者你们的目标客户的关键词 进入全球互联网上搜索您的目标客户信息 功能：智能邮件推广 提取客户邮箱信息，软件自动发送开发信联系客户 客户有意向采购您的产品就会回复询盘给您. （软件搜索-不限制关键词，不限制国家引擎） （软件群发-多主题 多内容 多帐号 防止屏蔽） 联系我们观看软件操作演示QQ服务号码（137 895 8561） --- 2015-2-9 15:51:34 20oi0V9U9Vg iVThi9h9h1U ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-ofctl: Implementation of eviction on the basis of Importance
Hi Ben, > > This commit enables the eviction mechanism on the basis of > > importance as > > per the openflow specification 1.4. > > > > ovs-ofctl -O OpenFlow14 mod-table evict > > -Enable eviction on of . Eviction adds a mechanism > > enabling the switch to automatically eliminate entries of lower > > importance to make space for newer entries.If want to enable > > eviction > > on all tables, user can set the as 'ALL'. > > > > ovs-ofctl -O OpenFlow14 mod-table noevict > > -Disable eviction on of . > > > > ovs-ofctl -O OpenFlow14 dump-tables-desc > > -This command provides a way to list the current configuration > > (eviction for importance) of the tables on a , which is > > set > > using the mod-table command. > > > > Signed-off-by: Saloni Jain > > Signed-off-by: Hiteshi Kalra > > I don't understand why OFPTC11_TABLE_MISS_MASK has something to do > with > enabling or disabling eviction. Please explain. Agreed, the same is not required. As part of initial patch submission we had this part of code but later on we removed the same while working/investigating on vacancy events. (FYI: we have freeze the code for vacancy events feature and after review of the current patch we will be submitting the same as some portion of code is dependent on the current patch) I will send the revised patch for "ovs-ofctl: Implementation of eviction on the basis of Importance" today i.e 11.02.2015. Thank you for the review. Rishi Thank You Regards Rishi Bamba =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3] docs: directly convert dot diagrams into eps for generating PDF
On Fri, Feb 06, 2015 at 11:14:13PM -0800, Ben Pfaff wrote: > On Tue, Feb 03, 2015 at 11:53:29PM -0800, Shu Shen wrote: > > The previous workflow is to convert dot diagrams into .pic format and > > embed into manpages; double borders and arrows were not used in dot but > > introduced in .pic conversion; edge routing in .pic was also worse than > > dot. > > > > The updated workflow specifies directly in dot diagram double > > boarders for "root set" nodes and solid/bold styles and arrows for > > edges. The converted .eps diagram has improved routing. The .eps diagram > > is embedded into PDF using groff PSPIC marco package when converting the > > manpages. PSPIC package is automatically loaded by groff when output to > > PS/PDF. > > > > In addition, 'constraint=false' option is removed from weak > > references to allow positioning of node boxes to avoid overlapping > > between multiple edges between "Mirror" and "Port" in > > ovs-vswitchd.conf.db. > > > > Signed-off-by: Shu Shen > > I guess this seems like a regression to me. Before, I could type "make > sandbox" then "groffer ovs-vswitchd.conf.db" and get a nice PDF manpage > with an E-R diagram. After, the diagram is gone. I looked at "groffer" script and I couldn't find a way to pass it an external dependency (.eps files). groffer copies the manpages to a /tmp folder and generates device files from there. Therefore, even if I managed to have .eps files installed properly along with the man page, they are not copied over to /tmp folders. The only way to make groffer work is to use embedded PIC diagram. The other choice is to keep embedded PIC diagram in the manpage and only have dist-docs replace with eps files when generating PDFs - but would this be too much a kludge to justify the benefit? Maybe I shall just drop the patch - and only include the fix for overlapping multiple edges by removing "constraint=fale"? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Processed: reassign 763428 linux-image-3.16.0-4-amd64
Processing commands for cont...@bugs.debian.org: > reassign 763428 linux-image-3.16.0-4-amd64 Bug #763428 [openvswitch-switch] openvswitch-switch: openvswitch doesn't work anymore since kernel 3.16 update Bug reassigned from package 'openvswitch-switch' to 'linux-image-3.16.0-4-amd64'. No longer marked as found in versions openvswitch/2.3.0+git20140819-2. Ignoring request to alter fixed versions of bug #763428 to the same values previously set > End of message, stopping processing here. Please contact me if you need assistance. -- 763428: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763428 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] lib/util.h: use types compatible with DWORD
Caveat: Unit tests are running and not complete yet. I’ll reply back once they
are complete.
thanks,
-- Nithin
> On Feb 10, 2015, at 4:38 PM, Nithin Raju wrote:
>
> _BitScanForward() and friends are part of the Windows API and
> take DWORD as parameter type. DWORD is defined to be 'unsigned long'
> in Windows' header files.
>
> We call into these functions from within lib/util.h. Currently, we
> pass arguments of type uint32_t which is type defined to
> 'unsigned int'. This incompatiblity causes failures when we compile
> the code as C++ code or with warnings enabled.
>
> The fix is to use 'unsigned long' rather than fixed size type.
>
> A simplied version of the problem is illustrated using a sample
> program:
> ---
> $ cat test.c
>
> void
> init_dword(DWORD *d)
> {
>*d = 0;
> }
>
> int main()
> {
>uint32_t u;
>
>init_dword(&u);
>
>return 0;
> }
>
> ===
> Problem manifests when warnings are enabled, and compiled as 'C' code:
> ===
> $ cl -WX -W4 test.c
> Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> test.c
> test.c(14) : error C2220: warning treated as error - no 'object' file
> generated
> test.c(14) : warning C4057: 'function' : 'DWORD *' differs in indirection to
> slightly different base types from 'uint32_t *'
>
> ===
> Problem manifests when code is compiled as 'C++' code:
> ===
> $ cl -Tptest.c
> Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> test.c
> test.c(14) : error C2664: 'void init_dword(DWORD *)' : cannot convert
> argument 1 from 'uint32_t *' to 'DWORD *'
>Types pointed to are unrelated; conversion requires reinterpret_cast,
> C-style cast or function-style cast
> ---
>
> Signed-off-by: Nithin Raju
> Co-Authored-by: Linda Sun
> ---
> lib/util.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/lib/util.h b/lib/util.h
> index cbaa3ac..276edb5 100644
> --- a/lib/util.h
> +++ b/lib/util.h
> @@ -352,11 +352,11 @@ static inline int
> raw_ctz(uint64_t n)
> {
> #ifdef _WIN64
> -uint32_t r = 0;
> +unsigned long r = 0;
> _BitScanForward64(&r, n);
> return r;
> #else
> -uint32_t low = n, high, r = 0;
> +unsigned long low = n, high, r = 0;
> if (_BitScanForward(&r, low)) {
> return r;
> }
> @@ -370,11 +370,11 @@ static inline int
> raw_clz64(uint64_t n)
> {
> #ifdef _WIN64
> -uint32_t r = 0;
> +unsigned long r = 0;
> _BitScanReverse64(&r, n);
> return 63 - r;
> #else
> -uint32_t low, high = n >> 32, r = 0;
> +unsigned long low, high = n >> 32, r = 0;
> if (_BitScanReverse(&r, high)) {
> return 31 - r;
> }
> --
> 1.9.4.msysgit.2
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3] net: openvswitch: Support masked set actions.
From: Jarno Rajahalme Date: Thu, 5 Feb 2015 13:40:49 -0800 > OVS userspace already probes the openvswitch kernel module for > OVS_ACTION_ATTR_SET_MASKED support. This patch adds the kernel module > implementation of masked set actions. > > The existing set action sets many fields at once. When only a subset > of the IP header fields, for example, should be modified, all the IP > fields need to be exact matched so that the other field values can be > copied to the set action. A masked set action allows modification of > an arbitrary subset of the supported header bits without requiring the > rest to be matched. > > Masked set action is now supported for all writeable key types, except > for the tunnel key. The set tunnel action is an exception as any > input tunnel info is cleared before action processing starts, so there > is no tunnel info to mask. > > The kernel module converts all (non-tunnel) set actions to masked set > actions. This makes action processing more uniform, and results in > less branching and duplicating the action processing code. When > returning actions to userspace, the fully masked set actions are > converted back to normal set actions. We use a kernel internal action > code to be able to tell the userspace provided and converted masked > set actions apart. > > Signed-off-by: Jarno Rajahalme > --- > v3: Clean up code and remove flow key transport port checks from > validate_set(), as suggested by Jesse Gross. Applied, thanks. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] netdev-dpdk: Allow changing NON_PMD_CORE_ID for testing purpose.
Pravin, Based on my test and Kevin's confirmation, I think it is safe to apply this patch for now. What do you think? Thanks, Alex Wang, ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 6/6] ofproto: Add NXM_NX_TUN_GBP_ID and NXM_NX_TUN_GBP_FLAGS
On 02/04/15 at 04:45pm, Thomas Graf wrote: > From: Madhu Challa > > Introduces two new NXMs to represent VXLAN-GBP [0] fields. > > actions=load:0x10->NXM_NX_TUN_GBP_ID[],NORMAL > tun_gbp_id=0x10,actions=drop > > This enables existing VXLAN tunnels to carry security label > information such as a SELinux context to other network peers. > > The values are carried to/from the datapath using the attribute > OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS. > > [0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy-00 > > Signed-off-by: Madhu Challa This last patch is still looking for a review. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] timeval: Correctly report usage statistics in log_poll_interval().
Most of the information that timeval was reporting for long poll intervals
was comparing per-thread with per-process statistics, which yielded
nonsense a lot of the time.
Signed-off-by: Ben Pfaff
---
lib/timeval.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/lib/timeval.c b/lib/timeval.c
index 6173aff..89d6cd6 100644
--- a/lib/timeval.c
+++ b/lib/timeval.c
@@ -102,6 +102,7 @@ DEFINE_STATIC_PER_THREAD_DATA(long long int, last_wakeup,
0);
static void log_poll_interval(long long int last_wakeup);
static struct rusage *get_recent_rusage(void);
+static int getrusage_thread(struct rusage *);
static void refresh_rusage(void);
static void timespec_add(struct timespec *sum,
const struct timespec *a, const struct timespec *b);
@@ -569,23 +570,26 @@ log_poll_interval(long long int last_wakeup)
&last_rusage->ru_utime),
timeval_diff_msec(&rusage.ru_stime,
&last_rusage->ru_stime));
-if (rusage.ru_minflt > last_rusage->ru_minflt
-|| rusage.ru_majflt > last_rusage->ru_majflt) {
-VLOG_WARN("faults: %ld minor, %ld major",
- rusage.ru_minflt - last_rusage->ru_minflt,
- rusage.ru_majflt - last_rusage->ru_majflt);
-}
-if (rusage.ru_inblock > last_rusage->ru_inblock
-|| rusage.ru_oublock > last_rusage->ru_oublock) {
-VLOG_WARN("disk: %ld reads, %ld writes",
- rusage.ru_inblock - last_rusage->ru_inblock,
- rusage.ru_oublock - last_rusage->ru_oublock);
-}
-if (rusage.ru_nvcsw > last_rusage->ru_nvcsw
-|| rusage.ru_nivcsw > last_rusage->ru_nivcsw) {
-VLOG_WARN("context switches: %ld voluntary, %ld involuntary",
- rusage.ru_nvcsw - last_rusage->ru_nvcsw,
- rusage.ru_nivcsw - last_rusage->ru_nivcsw);
+
+if (!getrusage_thread(&rusage)) {
+if (rusage.ru_minflt > last_rusage->ru_minflt
+|| rusage.ru_majflt > last_rusage->ru_majflt) {
+VLOG_WARN("faults: %ld minor, %ld major",
+ rusage.ru_minflt - last_rusage->ru_minflt,
+ rusage.ru_majflt - last_rusage->ru_majflt);
+}
+if (rusage.ru_inblock > last_rusage->ru_inblock
+|| rusage.ru_oublock > last_rusage->ru_oublock) {
+VLOG_WARN("disk: %ld reads, %ld writes",
+ rusage.ru_inblock - last_rusage->ru_inblock,
+ rusage.ru_oublock - last_rusage->ru_oublock);
+}
+if (rusage.ru_nvcsw > last_rusage->ru_nvcsw
+|| rusage.ru_nivcsw > last_rusage->ru_nivcsw) {
+VLOG_WARN("context switches: %ld voluntary, %ld involuntary",
+ rusage.ru_nvcsw - last_rusage->ru_nvcsw,
+ rusage.ru_nivcsw - last_rusage->ru_nivcsw);
+}
}
coverage_log();
}
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] openvswitch: Add missing initialization in validate_and_copy_set_tun()
On 02/11/15 at 11:23am, Geert Uytterhoeven wrote:
> net/openvswitch/flow_netlink.c: In function ‘validate_and_copy_set_tun’:
> net/openvswitch/flow_netlink.c:1749: warning: ‘err’ may be used uninitialized
> in this function
>
> If ipv4_tun_from_nlattr() returns a different positive value than
> OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS, err will be uninitialized, and
> validate_and_copy_set_tun() may return an undefined value instead of a
> zero success indicator. Initialize err to zero to fix this.
>
> Fixes: 1dd144cf5b4b47e1 ("openvswitch: Support VXLAN Group Policy extension")
> Signed-off-by: Geert Uytterhoeven
Acked-by: Thomas Graf
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/3] Add support for IETF Auto Attach standard (v5)
Ben, My apologies for the delay getting back to you on this topic. I am working on getting the tests you requested in place. As you suggest I will focus on adding a few tests to validate that we are sending well-formed LLDP packets. Specifically I will concentrate on validating the TLVs contained within LLDPPDUs generated for Auto Attach. As I mentioned in an earlier email I am coming up to speed on the OvS unit test framework but will back in touch with a new patch version ASAP. Regards, Dennis -Original Message- From: Ben Pfaff [mailto:b...@nicira.com] Sent: Wednesday, January 28, 2015 11:09 AM To: Flynn, Dennis R (Dennis) Cc: dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH 0/3] Add support for IETF Auto Attach standard (v5) Hi. I spent some more time on this series last night. I think that it needs some basic tests before I'll feel comfortable with it. Otherwise, there's no way to have any confidence that it hasn't been broken as part of changes in OVS as OVS evolves, or, more immediately, as part of style changes that I want to apply before it goes in. The part that I'm most concerned about is making sure that lldp packets being sent out are well-formed and contain the information that they should. Will you please work on getting some tests ready? Then we ought to be able to get this in pretty quickly. Thanks, Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] datapath: vxlan: Only set has-GBP bit in header if any other bits would be set
vxlan: Only set has-GBP bit in header if any other bits would be set
This allows for a VXLAN-GBP socket to talk to a Linux VXLAN socket by
not setting any of the bits.
Signed-off-by: Thomas Graf
Signed-off-by: David S. Miller
Upstream: db79a621835e ("vxlan: Only set has-GBP bit in header if any other
bits would be set")
Signed-off-by: Thomas Graf
---
datapath/linux/compat/vxlan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/datapath/linux/compat/vxlan.c b/datapath/linux/compat/vxlan.c
index 9d70611..84a039c 100644
--- a/datapath/linux/compat/vxlan.c
+++ b/datapath/linux/compat/vxlan.c
@@ -214,6 +214,9 @@ static void vxlan_build_gbp_hdr(struct vxlanhdr *vxh, u32
vxflags,
{
struct vxlanhdr_gbp *gbp;
+ if (!md->gbp)
+ return;
+
gbp = (struct vxlanhdr_gbp *)vxh;
vxh->vx_flags |= htonl(VXLAN_HF_GBP);
--
1.9.3
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
It's not the ofpbufs that are leaked. Where is 's' freed? Before your patch, the data in 's' was put into an ofpbuf, and eventually freed. After your patch, the data in 's' is always copied a second time, by ofpbuf_clone_data(), and then the copy is put into an ofpbuf (and eventually freed), but 's' itself appears to be leaked. On Mon, Feb 09, 2015 at 04:12:58PM +, Kavanagh, Mark B wrote: > Hi Ben, > > I don't think so - jsonrpc_run() empties the rpc output queue, freeing the > ofpbufs, after their contents are sent to the stream. > > Thanks, > Mark > > > -Original Message- > > From: Ben Pfaff [mailto:b...@nicira.com] > > Sent: Friday, February 6, 2015 8:41 PM > > To: Kavanagh, Mark B > > Cc: dev@openvswitch.org; Rory Sexton > > Subject: Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8 > > > > On Fri, Feb 06, 2015 at 04:43:26PM +, Mark Kavanagh wrote: > > > DPDK v1.8.0 makes significant changes to struct rte_mbuf, including > > > removal of the 'pkt' and 'data' fields. The latter, formally a > > > pointer, is now calculated via an offset from the start of the > > > segment buffer. These fields are referenced by OVS when accessing > > > the data section of an ofpbuf. > > > > > > The following changes are required to add support for DPDK 1.8: > > > - update affected functions to use the correct rte_mbuf fields > > > - remove init function from netdev-dpdk (no longer required as > > > rte_eal_pci_probe is now invoked from eal_init) > > > - split large amounts of data across multiple ofpbufs; with the > > > removal of the mbuf's 'data' pointer, and replacement with a > > > 'data_off' field, it is necessary to limit the size of data > > > contained in an ofpbuf to UINT16_MAX when mbufs are used > > > (data_off and data_len are both of type uint16_t). > > > Were data not split across multiple ofpbufs, values larger > > > than UINT16_MAX for 'data_len' and 'data_off' would result > > > in wrap-around, and consequently, data corruption. Changes > > > introduced in this patch prevent this from occurring. > > > > > > Signed-off-by: Mark Kavanagh > > > Signed-off-by: Mark Gray > > > Signed-off-by: Rory Sexton > > > > At first glance, at least, this patch introduces a memory leak into > > jsonrpc_send(). > > > > Thanks, > > > > Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] lib/util.h: use types compatible with DWORD
Unit tests pass except for 3 failures. 2 of them seem expected, and the third
one is with running ovsdb-server.exe as a Windows service. This does not seem
to be related to my change, and the failure seen without my change as well.
I’ll debug that as a separate issue.
thanks,
— Nithin
> On Feb 10, 2015, at 4:50 PM, Nithin Raju wrote:
>
> Caveat: Unit tests are running and not complete yet. I’ll reply back once
> they are complete.
>
> thanks,
> -- Nithin
>
>> On Feb 10, 2015, at 4:38 PM, Nithin Raju wrote:
>>
>> _BitScanForward() and friends are part of the Windows API and
>> take DWORD as parameter type. DWORD is defined to be 'unsigned long'
>> in Windows' header files.
>>
>> We call into these functions from within lib/util.h. Currently, we
>> pass arguments of type uint32_t which is type defined to
>> 'unsigned int'. This incompatiblity causes failures when we compile
>> the code as C++ code or with warnings enabled.
>>
>> The fix is to use 'unsigned long' rather than fixed size type.
>>
>> A simplied version of the problem is illustrated using a sample
>> program:
>> ---
>> $ cat test.c
>>
>> void
>> init_dword(DWORD *d)
>> {
>> *d = 0;
>> }
>>
>> int main()
>> {
>> uint32_t u;
>>
>> init_dword(&u);
>>
>> return 0;
>> }
>>
>> ===
>> Problem manifests when warnings are enabled, and compiled as 'C' code:
>> ===
>> $ cl -WX -W4 test.c
>> Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> test.c
>> test.c(14) : error C2220: warning treated as error - no 'object' file
>> generated
>> test.c(14) : warning C4057: 'function' : 'DWORD *' differs in indirection to
>> slightly different base types from 'uint32_t *'
>>
>> ===
>> Problem manifests when code is compiled as 'C++' code:
>> ===
>> $ cl -Tptest.c
>> Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> test.c
>> test.c(14) : error C2664: 'void init_dword(DWORD *)' : cannot convert
>> argument 1 from 'uint32_t *' to 'DWORD *'
>> Types pointed to are unrelated; conversion requires reinterpret_cast,
>> C-style cast or function-style cast
>> ---
>>
>> Signed-off-by: Nithin Raju
>> Co-Authored-by: Linda Sun
>> ---
>> lib/util.h | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/util.h b/lib/util.h
>> index cbaa3ac..276edb5 100644
>> --- a/lib/util.h
>> +++ b/lib/util.h
>> @@ -352,11 +352,11 @@ static inline int
>> raw_ctz(uint64_t n)
>> {
>> #ifdef _WIN64
>> -uint32_t r = 0;
>> +unsigned long r = 0;
>>_BitScanForward64(&r, n);
>>return r;
>> #else
>> -uint32_t low = n, high, r = 0;
>> +unsigned long low = n, high, r = 0;
>>if (_BitScanForward(&r, low)) {
>>return r;
>>}
>> @@ -370,11 +370,11 @@ static inline int
>> raw_clz64(uint64_t n)
>> {
>> #ifdef _WIN64
>> -uint32_t r = 0;
>> +unsigned long r = 0;
>>_BitScanReverse64(&r, n);
>>return 63 - r;
>> #else
>> -uint32_t low, high = n >> 32, r = 0;
>> +unsigned long low, high = n >> 32, r = 0;
>>if (_BitScanReverse(&r, high)) {
>>return 31 - r;
>>}
>> --
>> 1.9.4.msysgit.2
>>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] lib/util.h: use types compatible with DWORD
_BitScanForward() and friends are part of the Windows API and
take DWORD as parameter type. DWORD is defined to be 'unsigned long'
in Windows' header files.
We call into these functions from within lib/util.h. Currently, we
pass arguments of type uint32_t which is type defined to
'unsigned int'. This incompatiblity causes failures when we compile
the code as C++ code or with warnings enabled.
The fix is to use 'unsigned long' rather than fixed size type.
A simplied version of the problem is illustrated using a sample
program:
---
$ cat test.c
void
init_dword(DWORD *d)
{
*d = 0;
}
int main()
{
uint32_t u;
init_dword(&u);
return 0;
}
===
Problem manifests when warnings are enabled, and compiled as 'C' code:
===
$ cl -WX -W4 test.c
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
test.c
test.c(14) : error C2220: warning treated as error - no 'object' file generated
test.c(14) : warning C4057: 'function' : 'DWORD *' differs in indirection to
slightly different base types from 'uint32_t *'
===
Problem manifests when code is compiled as 'C++' code:
===
$ cl -Tptest.c
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
test.c
test.c(14) : error C2664: 'void init_dword(DWORD *)' : cannot convert argument
1 from 'uint32_t *' to 'DWORD *'
Types pointed to are unrelated; conversion requires reinterpret_cast,
C-style cast or function-style cast
---
Signed-off-by: Nithin Raju
Co-Authored-by: Linda Sun
---
lib/util.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/util.h b/lib/util.h
index cbaa3ac..276edb5 100644
--- a/lib/util.h
+++ b/lib/util.h
@@ -352,11 +352,11 @@ static inline int
raw_ctz(uint64_t n)
{
#ifdef _WIN64
-uint32_t r = 0;
+unsigned long r = 0;
_BitScanForward64(&r, n);
return r;
#else
-uint32_t low = n, high, r = 0;
+unsigned long low = n, high, r = 0;
if (_BitScanForward(&r, low)) {
return r;
}
@@ -370,11 +370,11 @@ static inline int
raw_clz64(uint64_t n)
{
#ifdef _WIN64
-uint32_t r = 0;
+unsigned long r = 0;
_BitScanReverse64(&r, n);
return 63 - r;
#else
-uint32_t low, high = n >> 32, r = 0;
+unsigned long low, high = n >> 32, r = 0;
if (_BitScanReverse(&r, high)) {
return 31 - r;
}
--
1.9.4.msysgit.2
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] daemon.at: Fix a race condition with windows service test.
OVS daemon service for Windows creates the pidfile and then registers with the Windows services manager that the service is running. There is a small time gap between the two steps. So retry a few times in the test. Also, provide a keyword for the test. Reported-by: Nithin Raju Signed-off-by: Gurucharan Shetty --- tests/daemon.at |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/daemon.at b/tests/daemon.at index 4a6f341..dd7a3f4 100644 --- a/tests/daemon.at +++ b/tests/daemon.at @@ -161,6 +161,7 @@ AT_CHECK([test ! -s pid]) AT_CLEANUP AT_SETUP([daemon --service]) +AT_KEYWORDS([windows-service]) AT_SKIP_IF([test "$IS_WIN32" != "yes"]) OVSDB_INIT([db]) AT_CAPTURE_FILE([pid]) @@ -173,7 +174,7 @@ AT_CHECK([sc create ovsdb-server binpath="$abs_path/ovsdb-server `pwd`/db --log- AT_CHECK([sc start ovsdb-server], [0], [ignore]) OVS_WAIT_UNTIL([test -s pid]) -AT_CHECK([sc query ovsdb-server | grep STATE | grep RUNNING], [0], [ignore]) +OVS_WAIT_UNTIL([sc query ovsdb-server | grep STATE | grep RUNNING > /dev/null 2>&1]) AT_CHECK([kill -0 `cat pid`], [0], [ignore]) AT_CHECK([ovs-appctl -t `pwd`/unixctl ovsdb-server/list-dbs], [0], [Open_vSwitch -- 1.7.9.5 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Dear Sir/Madam,
Dear Sir/Madam ! Hope you are fine? My name is Alice Joe from London UK, Please kindly reply so i can fully introduce myself and also share the reasons why i contacted you. Thanks best regards. Alice. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/3] Add support for IETF Auto Attach standard (v5)
That's great, I'm looking forward to the new version. Let me know if you can't figure out the test framework. The best place to start on it is the "Using Autotest" chapter in the Autoconf manual. On Tue, Feb 10, 2015 at 02:37:29PM +, Flynn, Dennis R (Dennis) wrote: > Ben, > > My apologies for the delay getting back to you on this topic. > > I am working on getting the tests you requested in place. As you suggest I > will focus on adding a few tests to validate that we are sending well-formed > LLDP packets. Specifically I will concentrate on validating the TLVs > contained within LLDPPDUs generated for Auto Attach. > > As I mentioned in an earlier email I am coming up to speed on the OvS unit > test framework but will back in touch with a new patch version ASAP. > > Regards, > Dennis > > > -Original Message- > From: Ben Pfaff [mailto:b...@nicira.com] > Sent: Wednesday, January 28, 2015 11:09 AM > To: Flynn, Dennis R (Dennis) > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] [PATCH 0/3] Add support for IETF Auto Attach standard > (v5) > > Hi. I spent some more time on this series last night. I think that it needs > some basic tests before I'll feel comfortable with it. Otherwise, there's no > way to have any confidence that it hasn't been broken as part of changes in > OVS as OVS evolves, or, more immediately, as part of style changes that I > want to apply before it goes in. > > The part that I'm most concerned about is making sure that lldp packets being > sent out are well-formed and contain the information that they should. > > Will you please work on getting some tests ready? Then we ought to be able > to get this in pretty quickly. > > Thanks, > > Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] tests: Enable running parallel unit tests for Windows.
testsuite uses mkfifo in its job dispatcher that manages
parallel unit tests. MinGW does not have a mkfifo. This
results in unit tests running serially on Windows. Right
now it takes up to approximately 40 minutes to run all the
unit tests on Windows.
This commit provides a job dispatcher for MinGW that uses
temporary files instead of mkfifo to manage parallel jobs.
With this commit, on a Windows machine with 4 cores and with
8 parallel unit test sessions, it takes approximately 8
minutes to finish a unit test run.
Signed-off-by: Gurucharan Shetty
---
tests/automake.mk |7 +++--
tests/testsuite.patch | 75 +
2 files changed, 80 insertions(+), 2 deletions(-)
create mode 100644 tests/testsuite.patch
diff --git a/tests/automake.mk b/tests/automake.mk
index 2e8d213..7235744 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -6,7 +6,8 @@ EXTRA_DIST += \
$(KMOD_TESTSUITE) \
tests/atlocal.in \
$(srcdir)/package.m4 \
- $(srcdir)/tests/testsuite
+ $(srcdir)/tests/testsuite \
+ $(srcdir)/tests/testsuite.patch
COMMON_MACROS_AT = \
tests/ovsdb-macros.at \
@@ -87,6 +88,7 @@ KMOD_TESTSUITE_AT = \
tests/kmod-traffic.at
TESTSUITE = $(srcdir)/tests/testsuite
+TESTSUITE_PATCH = $(srcdir)/tests/testsuite.patch
KMOD_TESTSUITE = $(srcdir)/tests/kmod-testsuite
DISTCLEANFILES += tests/atconfig tests/atlocal
@@ -196,9 +198,10 @@ clean-local:
test ! -f '$(TESTSUITE)' || $(SHELL) '$(TESTSUITE)' -C tests --clean
AUTOTEST = $(AUTOM4TE) --language=autotest
-$(TESTSUITE): package.m4 $(TESTSUITE_AT) $(COMMON_MACROS_AT)
+$(TESTSUITE): package.m4 $(TESTSUITE_AT) $(COMMON_MACROS_AT) $(TESTSUITE_PATCH)
$(AM_V_GEN)$(AUTOTEST) -I '$(srcdir)' -o $@.tmp $@.at
$(AM_V_at)mv $@.tmp $@
+ patch -p0 $(TESTSUITE) $(TESTSUITE_PATCH)
$(KMOD_TESTSUITE): package.m4 $(KMOD_TESTSUITE_AT) $(COMMON_MACROS_AT)
$(AM_V_GEN)$(AUTOTEST) -I '$(srcdir)' -o $@.tmp $@.at
diff --git a/tests/testsuite.patch b/tests/testsuite.patch
new file mode 100644
index 000..b0736c1
--- /dev/null
+++ b/tests/testsuite.patch
@@ -0,0 +1,75 @@
+--- testsuite 2015-02-11 07:20:45.863908878 -0800
testsuite 2015-02-11 07:08:49.803934047 -0800
+@@ -4669,6 +4669,72 @@
+ fi
+ exec 6<&-
+ wait
++elif [ "$IS_WIN32" = "yes" ]; then
++ # FIFO job dispatcher.
++ trap 'at_pids=
++ for at_pid in `jobs -p`; do
++at_pids="$at_pids $at_job_group$at_pid"
++ done
++ if test -n "$at_pids"; then
++at_sig=TSTP
++test "${TMOUT+set}" = set && at_sig=STOP
++kill -$at_sig $at_pids 2>/dev/null
++ fi
++ kill -STOP $$
++ test -z "$at_pids" || kill -CONT $at_pids 2>/dev/null' TSTP
++
++ echo
++ # Turn jobs into a list of numbers, starting from 1.
++ running_jobs="`pwd`/tests/jobdispatcher"
++ mkdir -p $running_jobs
++ at_joblist=`$as_echo "$at_groups" | sed -n 1,${at_jobs}p`
++
++ set X $at_joblist
++ shift
++ for at_group in $at_groups; do
++$at_job_control_on 2>/dev/null
++(
++ # Start one test group.
++ $at_job_control_off
++ touch $running_jobs/$at_group
++ trap 'set +x; set +e
++ trap "" PIPE
++ echo stop > "$at_stop_file"
++ rm -f $running_jobs/$at_group
++ as_fn_exit 141' PIPE
++ at_fn_group_prepare
++ if cd "$at_group_dir" &&
++ at_fn_test $at_group &&
++ . "$at_test_source"
++ then :; else
++ { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: unable to parse test
group: $at_group" >&5
++$as_echo "$as_me: WARNING: unable to parse test group: $at_group" >&2;}
++ at_failed=:
++ fi
++ rm -f $running_jobs/$at_group
++ at_fn_group_postprocess
++) &
++$at_job_control_off
++shift # Consume one token.
++if test $# -gt 0; then :; else
++ while [ "`ls -l $running_jobs 2>/dev/null | wc -l`" -gt "$at_jobs" ]; do
++sleep 0.1
++ done
++ set x $*
++fi
++test -f "$at_stop_file" && break
++ done
++ # Read back the remaining ($at_jobs - 1) tokens.
++ set X $at_joblist
++ shift
++ if test $# -gt 0; then
++shift
++while [ "`ls -l $running_jobs | wc -l`" -gt 1 ]; do
++ sleep 0.1
++done
++ fi
++ rmdir $running_jobs
++ wait
+ else
+ # Run serially, avoid forks and other potential surprises.
+ for at_group in $at_groups; do
--
1.7.9.5
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] Preserve IPv6 link-local address on interface save
If IPv6 link-local address is removed from interface, it is unable to
receive any IPv6 packets, including Route Advertisements.
In save_interface only skip IPv4 "scope link" addresses.
Signed-off-by: Alexey I. Froloff
---
utilities/ovs-save | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/utilities/ovs-save b/utilities/ovs-save
index 4478a3a..7c6390d 100755
--- a/utilities/ovs-save
+++ b/utilities/ovs-save
@@ -100,9 +100,10 @@ save_interfaces () {
continue 2
;;
scope)
-if test "$2" = link; then
+if test "$2" = link -a "$family" != inet6; then
# Omit route derived from IP address, e.g.
-# 172.16.0.0/16 derived from 172.16.12.34.
+# 172.16.0.0/16 derived from 172.16.12.34,
+# but preserve IPv6 link-local address.
continue 2
fi
;;
--
2.1.0
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 11/13] datapath: Allow building against 3.19.x
On Sat, Feb 07, 2015 at 01:04:57PM +0100, Thomas Graf wrote: > On 02/06/15 at 10:28pm, Ben Pfaff wrote: > > We already do a ton of kernel module builds in travis, do you mean that > > we should do one for every released kernel, or do you mean something > > else? > > I'm primarily thinking of Andy's work to enable runtime CI as well. > I think the matrix of stable kernels is fine. Oh, yes, that would be very nice. I wonder whether user-mode Linux is usable enough to test OVS. I built a related prototype back in 2008 or so, but I never managed to automate it properly. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] datapath: vxlan: Only set has-GBP bit in header if any other bits would be set
On Mon, Feb 9, 2015 at 7:54 AM, Thomas Graf wrote:
> vxlan: Only set has-GBP bit in header if any other bits would be set
>
> This allows for a VXLAN-GBP socket to talk to a Linux VXLAN socket by
> not setting any of the bits.
>
> Signed-off-by: Thomas Graf
> Signed-off-by: David S. Miller
>
> Upstream: db79a621835e ("vxlan: Only set has-GBP bit in header if any other
> bits would be set")
> Signed-off-by: Thomas Graf
Acked-by: Pravin B Shelar
> ---
> datapath/linux/compat/vxlan.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/datapath/linux/compat/vxlan.c b/datapath/linux/compat/vxlan.c
> index 9d70611..84a039c 100644
> --- a/datapath/linux/compat/vxlan.c
> +++ b/datapath/linux/compat/vxlan.c
> @@ -214,6 +214,9 @@ static void vxlan_build_gbp_hdr(struct vxlanhdr *vxh, u32
> vxflags,
> {
> struct vxlanhdr_gbp *gbp;
>
> + if (!md->gbp)
> + return;
> +
> gbp = (struct vxlanhdr_gbp *)vxh;
> vxh->vx_flags |= htonl(VXLAN_HF_GBP);
>
> --
> 1.9.3
>
> ___
> 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.at: Fix a race condition with windows service test.
> On Feb 11, 2015, at 2:15 PM, Gurucharan Shetty wrote: > > OVS daemon service for Windows creates the pidfile and then > registers with the Windows services manager that the service > is running. There is a small time gap between the two steps. > So retry a few times in the test. > > Also, provide a keyword for the test. > > Reported-by: Nithin Raju > Signed-off-by: Gurucharan Shetty Acked-by: Nithin Raju Tested-by: Nithin Raju ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] lib/util.h: use types compatible with DWORD
On Tue, Feb 10, 2015 at 4:38 PM, Nithin Raju wrote:
> _BitScanForward() and friends are part of the Windows API and
> take DWORD as parameter type. DWORD is defined to be 'unsigned long'
> in Windows' header files.
>
> We call into these functions from within lib/util.h. Currently, we
> pass arguments of type uint32_t which is type defined to
> 'unsigned int'. This incompatiblity causes failures when we compile
> the code as C++ code or with warnings enabled.
>
> The fix is to use 'unsigned long' rather than fixed size type.
>
> A simplied version of the problem is illustrated using a sample
> program:
> ---
> $ cat test.c
>
> void
> init_dword(DWORD *d)
> {
> *d = 0;
> }
>
> int main()
> {
> uint32_t u;
>
> init_dword(&u);
>
> return 0;
> }
>
> ===
> Problem manifests when warnings are enabled, and compiled as 'C' code:
> ===
> $ cl -WX -W4 test.c
> Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> test.c
> test.c(14) : error C2220: warning treated as error - no 'object' file
> generated
> test.c(14) : warning C4057: 'function' : 'DWORD *' differs in indirection to
> slightly different base types from 'uint32_t *'
>
> ===
> Problem manifests when code is compiled as 'C++' code:
> ===
> $ cl -Tptest.c
> Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> test.c
> test.c(14) : error C2664: 'void init_dword(DWORD *)' : cannot convert
> argument 1 from 'uint32_t *' to 'DWORD *'
> Types pointed to are unrelated; conversion requires reinterpret_cast,
> C-style cast or function-style cast
> ---
>
> Signed-off-by: Nithin Raju
> Co-Authored-by: Linda Sun
This will need a Signed-off-by from Linda too.
> ---
> lib/util.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/lib/util.h b/lib/util.h
> index cbaa3ac..276edb5 100644
> --- a/lib/util.h
> +++ b/lib/util.h
> @@ -352,11 +352,11 @@ static inline int
> raw_ctz(uint64_t n)
> {
> #ifdef _WIN64
> -uint32_t r = 0;
> +unsigned long r = 0;
> _BitScanForward64(&r, n);
> return r;
> #else
> -uint32_t low = n, high, r = 0;
> +unsigned long low = n, high, r = 0;
> if (_BitScanForward(&r, low)) {
> return r;
> }
> @@ -370,11 +370,11 @@ static inline int
> raw_clz64(uint64_t n)
> {
> #ifdef _WIN64
> -uint32_t r = 0;
> +unsigned long r = 0;
> _BitScanReverse64(&r, n);
> return 63 - r;
> #else
> -uint32_t low, high = n >> 32, r = 0;
> +unsigned long low, high = n >> 32, r = 0;
> if (_BitScanReverse(&r, high)) {
> return 31 - r;
> }
> --
> 1.9.4.msysgit.2
>
> ___
> 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.at: Fix a race condition with windows service test.
On Wed, Feb 11, 2015 at 4:09 PM, Nithin Raju wrote: >> On Feb 11, 2015, at 2:15 PM, Gurucharan Shetty wrote: >> >> OVS daemon service for Windows creates the pidfile and then >> registers with the Windows services manager that the service >> is running. There is a small time gap between the two steps. >> So retry a few times in the test. >> >> Also, provide a keyword for the test. >> >> Reported-by: Nithin Raju >> Signed-off-by: Gurucharan Shetty > > Acked-by: Nithin Raju > Tested-by: Nithin Raju Thanks, applied! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] tests: Enable running parallel unit tests for Windows.
On Wed, Feb 11, 2015 at 02:16:51PM -0800, Gurucharan Shetty wrote: > testsuite uses mkfifo in its job dispatcher that manages > parallel unit tests. MinGW does not have a mkfifo. This > results in unit tests running serially on Windows. Right > now it takes up to approximately 40 minutes to run all the > unit tests on Windows. > > This commit provides a job dispatcher for MinGW that uses > temporary files instead of mkfifo to manage parallel jobs. > With this commit, on a Windows machine with 4 cores and with > 8 parallel unit test sessions, it takes approximately 8 > minutes to finish a unit test run. > > Signed-off-by: Gurucharan Shetty Thanks for doing this. I really like changes that make it easier or faster to run tests, because then developers are more likely to run them. I don't think that "patch" is currently required to build OVS. I think that it's reasonable to require it--it is such a common utility--but I think that we should mention it in INSTALL.md. In the Makefile fragment, I would prefer to apply the patch before renaming the file. That way, the new version of the testsuite appears atomically. > ++elif [ "$IS_WIN32" = "yes" ]; then The UNIX version of the parallel dispatcher has a few more tests: if test $at_jobs -ne 1 && rm -f "$at_job_fifo" && test -n "$at_job_group" && ( mkfifo "$at_job_fifo" && trap 'exit 1' PIPE STOP TSTP ) 2>/dev/null Maybe it is worth checking at least that $at_jobs > 1? Thanks, Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] ovsdb-idl
It's difficult to design and maintain a shared library with a stable public API and ABI. No one has done the work yet. On Tue, Feb 10, 2015 at 07:25:47PM +, Papudippu, Sreedhar Reddy wrote: > Hello all, > > I have been wondering why doesn open-vswitch code links the entire > "lib/libopenvswitch.la" into every binary in the code. > > Isn't that very in-efficient? Shouldn't we create separate libraries based on > some logical divide, and then link the libraries based on the need. > > We should have created the following libraries in the source code. > 1) LACP.a. > 2) Sflow.a > 3) Vlog.a > 4) Ovsdb_client.a > 5) Etc.. > > That will give flexibility to developers who want to create their own tools > based on open-vswitch code. > > With the current design, a developer has to link almost the entire > "lib/libopenvswitch.la" even in a small tool which uses ovsdb. > > Can someone through some history behind this design. > > If there is no specific reason, can I separate these things into small > logical libraries and submit the patch? > > Regards > Sreedhar > _ > From: Papudippu, Sreedhar Reddy > Sent: Monday, February 09, 2015 3:10 PM > To: dev@openvswitch.org > Subject: ovsdb-idl > > > Hello all, > > I was wondering why "ovsdb-idl" client API code is not made as a separate > independent library. > > Assume if someone wants to write a new client for the ovsdb-idl, how will > he/she link the code to the source library? > How will he/she get the get the header file definitions? > > Regards > Sreedhar > > ___ > 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 11/13] datapath: Allow building against 3.19.x
I have experimented with the user-mode linux about a month back. I was not able to get ovs user space to run reliably with the (light weight) host-fs file system. It may run better with a disk-image (I did not try), but then we willl have to deal with building and distributing disk-images, which Vagrant solves. On Sat, Feb 7, 2015 at 10:52 PM, Ben Pfaff wrote: > On Sat, Feb 07, 2015 at 01:04:57PM +0100, Thomas Graf wrote: >> On 02/06/15 at 10:28pm, Ben Pfaff wrote: >> > We already do a ton of kernel module builds in travis, do you mean that >> > we should do one for every released kernel, or do you mean something >> > else? >> >> I'm primarily thinking of Andy's work to enable runtime CI as well. >> I think the matrix of stable kernels is fine. > > Oh, yes, that would be very nice. > > I wonder whether user-mode Linux is usable enough to test OVS. I built > a related prototype back in 2008 or so, but I never managed to automate > it properly. > ___ > 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] tests: Enable running parallel unit tests for Windows.
> > Thanks for doing this. I really like changes that make it easier or > faster to run tests, because then developers are more likely to run > them. > > I don't think that "patch" is currently required to build OVS. I think > that it's reasonable to require it--it is such a common utility--but I > think that we should mention it in INSTALL.md. > > In the Makefile fragment, I would prefer to apply the patch before > renaming the file. That way, the new version of the testsuite appears > atomically. > >> ++elif [ "$IS_WIN32" = "yes" ]; then > > The UNIX version of the parallel dispatcher has a few more tests: > > if test $at_jobs -ne 1 && > rm -f "$at_job_fifo" && > test -n "$at_job_group" && > ( mkfifo "$at_job_fifo" && trap 'exit 1' PIPE STOP TSTP ) 2>/dev/null > > Maybe it is worth checking at least that $at_jobs > 1? All agreed. I will send a v2. > > Thanks, > > Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] ovsdb-idl
Hi Ben, I do understand that making it as a Shared library brings in lot of troubles, due to the decoupling. But I am trying to make it as Static library (ovsdb-idl.a), so that if an external tool/application use the Ovsdb-ild library without carrying the rest of the baggage from open-switch/lib/*. If making the OVSDB-IDL code as a seperate static library is acceptable I can submit a patch for that. Regards Sreedhar -Original Message- From: Ben Pfaff [mailto:b...@nicira.com] Sent: Wednesday, February 11, 2015 6:55 PM To: Papudippu, Sreedhar Reddy Cc: dev@openvswitch.org Subject: Re: [ovs-dev] ovsdb-idl It's difficult to design and maintain a shared library with a stable public API and ABI. No one has done the work yet. On Tue, Feb 10, 2015 at 07:25:47PM +, Papudippu, Sreedhar Reddy wrote: > Hello all, > > I have been wondering why doesn open-vswitch code links the entire > "lib/libopenvswitch.la" into every binary in the code. > > Isn't that very in-efficient? Shouldn't we create separate libraries based on > some logical divide, and then link the libraries based on the need. > > We should have created the following libraries in the source code. > 1) LACP.a. > 2) Sflow.a > 3) Vlog.a > 4) Ovsdb_client.a > 5) Etc.. > > That will give flexibility to developers who want to create their own tools > based on open-vswitch code. > > With the current design, a developer has to link almost the entire > "lib/libopenvswitch.la" even in a small tool which uses ovsdb. > > Can someone through some history behind this design. > > If there is no specific reason, can I separate these things into small > logical libraries and submit the patch? > > Regards > Sreedhar > _ > From: Papudippu, Sreedhar Reddy > Sent: Monday, February 09, 2015 3:10 PM > To: dev@openvswitch.org > Subject: ovsdb-idl > > > Hello all, > > I was wondering why "ovsdb-idl" client API code is not made as a separate > independent library. > > Assume if someone wants to write a new client for the ovsdb-idl, how will > he/she link the code to the source library? > How will he/she get the get the header file definitions? > > Regards > Sreedhar > > ___ > 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 v2] tests: Enable running parallel unit tests for Windows.
testsuite uses mkfifo in its job dispatcher that manages
parallel unit tests. MinGW does not have a mkfifo. This
results in unit tests running serially on Windows. Right
now it takes up to approximately 40 minutes to run all the
unit tests on Windows.
This commit provides a job dispatcher for MinGW that uses
temporary files instead of mkfifo to manage parallel jobs.
With this commit, on a Windows machine with 4 cores and with
8 parallel unit test sessions, it takes approximately 8
minutes to finish a unit test run.
Signed-off-by: Gurucharan Shetty
---
INSTALL.md|2 ++
tests/automake.mk |7 +++--
tests/testsuite.patch | 76 +
3 files changed, 83 insertions(+), 2 deletions(-)
create mode 100644 tests/testsuite.patch
diff --git a/INSTALL.md b/INSTALL.md
index 94c25f7..273093b 100644
--- a/INSTALL.md
+++ b/INSTALL.md
@@ -41,6 +41,8 @@ you will need the following software:
- Python 2.x, for x >= 4.
+ - patch (The utility that is used to patch files).
+
On Linux, you may choose to compile the kernel module that comes with
the Open vSwitch distribution or to use the kernel module built into
the Linux kernel (version 3.3 or later). See the [FAQ.md] question
diff --git a/tests/automake.mk b/tests/automake.mk
index 2e8d213..50d8ad2 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -6,7 +6,8 @@ EXTRA_DIST += \
$(KMOD_TESTSUITE) \
tests/atlocal.in \
$(srcdir)/package.m4 \
- $(srcdir)/tests/testsuite
+ $(srcdir)/tests/testsuite \
+ $(srcdir)/tests/testsuite.patch
COMMON_MACROS_AT = \
tests/ovsdb-macros.at \
@@ -87,6 +88,7 @@ KMOD_TESTSUITE_AT = \
tests/kmod-traffic.at
TESTSUITE = $(srcdir)/tests/testsuite
+TESTSUITE_PATCH = $(srcdir)/tests/testsuite.patch
KMOD_TESTSUITE = $(srcdir)/tests/kmod-testsuite
DISTCLEANFILES += tests/atconfig tests/atlocal
@@ -196,8 +198,9 @@ clean-local:
test ! -f '$(TESTSUITE)' || $(SHELL) '$(TESTSUITE)' -C tests --clean
AUTOTEST = $(AUTOM4TE) --language=autotest
-$(TESTSUITE): package.m4 $(TESTSUITE_AT) $(COMMON_MACROS_AT)
+$(TESTSUITE): package.m4 $(TESTSUITE_AT) $(COMMON_MACROS_AT) $(TESTSUITE_PATCH)
$(AM_V_GEN)$(AUTOTEST) -I '$(srcdir)' -o $@.tmp $@.at
+ patch -p0 $@.tmp $(TESTSUITE_PATCH)
$(AM_V_at)mv $@.tmp $@
$(KMOD_TESTSUITE): package.m4 $(KMOD_TESTSUITE_AT) $(COMMON_MACROS_AT)
diff --git a/tests/testsuite.patch b/tests/testsuite.patch
new file mode 100644
index 000..e0c6bb3
--- /dev/null
+++ b/tests/testsuite.patch
@@ -0,0 +1,76 @@
+--- testsuite 2015-02-11 17:19:21.654646439 -0800
testsuite 2015-02-11 17:15:03.810653032 -0800
+@@ -4669,6 +4669,73 @@
+ fi
+ exec 6<&-
+ wait
++elif test $at_jobs -ne 1 &&
++ test "$IS_WIN32" = "yes"; then
++ # FIFO job dispatcher.
++ trap 'at_pids=
++ for at_pid in `jobs -p`; do
++at_pids="$at_pids $at_job_group$at_pid"
++ done
++ if test -n "$at_pids"; then
++at_sig=TSTP
++test "${TMOUT+set}" = set && at_sig=STOP
++kill -$at_sig $at_pids 2>/dev/null
++ fi
++ kill -STOP $$
++ test -z "$at_pids" || kill -CONT $at_pids 2>/dev/null' TSTP
++
++ echo
++ # Turn jobs into a list of numbers, starting from 1.
++ running_jobs="`pwd`/tests/jobdispatcher"
++ mkdir -p $running_jobs
++ at_joblist=`$as_echo "$at_groups" | sed -n 1,${at_jobs}p`
++
++ set X $at_joblist
++ shift
++ for at_group in $at_groups; do
++$at_job_control_on 2>/dev/null
++(
++ # Start one test group.
++ $at_job_control_off
++ touch $running_jobs/$at_group
++ trap 'set +x; set +e
++ trap "" PIPE
++ echo stop > "$at_stop_file"
++ rm -f $running_jobs/$at_group
++ as_fn_exit 141' PIPE
++ at_fn_group_prepare
++ if cd "$at_group_dir" &&
++ at_fn_test $at_group &&
++ . "$at_test_source"
++ then :; else
++ { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: unable to parse test
group: $at_group" >&5
++$as_echo "$as_me: WARNING: unable to parse test group: $at_group" >&2;}
++ at_failed=:
++ fi
++ rm -f $running_jobs/$at_group
++ at_fn_group_postprocess
++) &
++$at_job_control_off
++shift # Consume one token.
++if test $# -gt 0; then :; else
++ while [ "`ls -l $running_jobs 2>/dev/null | wc -l`" -gt "$at_jobs" ]; do
++sleep 0.1
++ done
++ set x $*
++fi
++test -f "$at_stop_file" && break
++ done
++ # Read back the remaining ($at_jobs - 1) tokens.
++ set X $at_joblist
++ shift
++ if test $# -gt 0; then
++shift
++while [ "`ls -l $running_jobs | wc -l`" -gt 1 ]; do
++ sleep 0.1
++done
++ fi
++ rmdir $running_jobs
++ wait
+ else
+ # Run serially, avoid forks and other potential surprises.
+ for at_group in $at_groups; do
--
1.7.9.5
___
dev mailing list
dev@openvswitch.org
http://openvs
Re: [ovs-dev] ovsdb-idl
What kind of problems do you have with the rest of the library? Maybe we should focus on that. On Thu, Feb 12, 2015 at 02:56:15AM +, Papudippu, Sreedhar Reddy wrote: > Hi Ben, > > I do understand that making it as a Shared library brings in lot of troubles, > due to the decoupling. > But I am trying to make it as Static library (ovsdb-idl.a), so that if an > external tool/application use the Ovsdb-ild library without carrying the rest > of the baggage from open-switch/lib/*. > > If making the OVSDB-IDL code as a seperate static library is acceptable I can > submit a patch for that. > > Regards > Sreedhar > > -Original Message- > From: Ben Pfaff [mailto:b...@nicira.com] > Sent: Wednesday, February 11, 2015 6:55 PM > To: Papudippu, Sreedhar Reddy > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] ovsdb-idl > > It's difficult to design and maintain a shared library with a stable public > API and ABI. No one has done the work yet. > > On Tue, Feb 10, 2015 at 07:25:47PM +, Papudippu, Sreedhar Reddy wrote: > > Hello all, > > > > I have been wondering why doesn open-vswitch code links the entire > > "lib/libopenvswitch.la" into every binary in the code. > > > > Isn't that very in-efficient? Shouldn't we create separate libraries based > > on some logical divide, and then link the libraries based on the need. > > > > We should have created the following libraries in the source code. > > 1) LACP.a. > > 2) Sflow.a > > 3) Vlog.a > > 4) Ovsdb_client.a > > 5) Etc.. > > > > That will give flexibility to developers who want to create their own tools > > based on open-vswitch code. > > > > With the current design, a developer has to link almost the entire > > "lib/libopenvswitch.la" even in a small tool which uses ovsdb. > > > > Can someone through some history behind this design. > > > > If there is no specific reason, can I separate these things into small > > logical libraries and submit the patch? > > > > Regards > > Sreedhar > > _ > > From: Papudippu, Sreedhar Reddy > > Sent: Monday, February 09, 2015 3:10 PM > > To: dev@openvswitch.org > > Subject: ovsdb-idl > > > > > > Hello all, > > > > I was wondering why "ovsdb-idl" client API code is not made as a separate > > independent library. > > > > Assume if someone wants to write a new client for the ovsdb-idl, how will > > he/she link the code to the source library? > > How will he/she get the get the header file definitions? > > > > Regards > > Sreedhar > > > > ___ > > 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 11/13] datapath: Allow building against 3.19.x
Vagrant sounds like a real winner. Thanks for working on the kernel testing infrastructure. I hope that we can start to build up a library of tests. On Wed, Feb 11, 2015 at 06:04:31PM -0800, Andy Zhou wrote: > I have experimented with the user-mode linux about a month back. I was > not able to get ovs user space to run reliably with the > (light weight) host-fs file system. It may run better with a > disk-image (I did not try), but then we willl have to deal with > building > and distributing disk-images, which Vagrant solves. > > On Sat, Feb 7, 2015 at 10:52 PM, Ben Pfaff wrote: > > On Sat, Feb 07, 2015 at 01:04:57PM +0100, Thomas Graf wrote: > >> On 02/06/15 at 10:28pm, Ben Pfaff wrote: > >> > We already do a ton of kernel module builds in travis, do you mean that > >> > we should do one for every released kernel, or do you mean something > >> > else? > >> > >> I'm primarily thinking of Andy's work to enable runtime CI as well. > >> I think the matrix of stable kernels is fine. > > > > Oh, yes, that would be very nice. > > > > I wonder whether user-mode Linux is usable enough to test OVS. I built > > a related prototype back in 2008 or so, but I never managed to automate > > it properly. > > ___ > > 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] ovsdb-idl
Hi Ben, I am trying to write few applications which are pure clients to OVSDB. I need to link with OVSDB-IDL. Currently the only way I can link with ovsdb-idl is by linking the with lib/libopenvswitch.la Currently lib/libopenvswitch.la has sFlow, LACP, netdev-provider etc code together. When I link my binary with lib/libopenvswitch.la, then I carry over all the above code pieces, which I am not interested in. That's why I want pure ovsdb-idl as a separate library. Regards Sreedhar -Original Message- From: Ben Pfaff [mailto:b...@nicira.com] Sent: Wednesday, February 11, 2015 9:41 PM To: Papudippu, Sreedhar Reddy Cc: dev@openvswitch.org Subject: Re: [ovs-dev] ovsdb-idl What kind of problems do you have with the rest of the library? Maybe we should focus on that. On Thu, Feb 12, 2015 at 02:56:15AM +, Papudippu, Sreedhar Reddy wrote: > Hi Ben, > > I do understand that making it as a Shared library brings in lot of troubles, > due to the decoupling. > But I am trying to make it as Static library (ovsdb-idl.a), so that if an > external tool/application use the Ovsdb-ild library without carrying the rest > of the baggage from open-switch/lib/*. > > If making the OVSDB-IDL code as a seperate static library is acceptable I can > submit a patch for that. > > Regards > Sreedhar > > -Original Message- > From: Ben Pfaff [mailto:b...@nicira.com] > Sent: Wednesday, February 11, 2015 6:55 PM > To: Papudippu, Sreedhar Reddy > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] ovsdb-idl > > It's difficult to design and maintain a shared library with a stable public > API and ABI. No one has done the work yet. > > On Tue, Feb 10, 2015 at 07:25:47PM +, Papudippu, Sreedhar Reddy wrote: > > Hello all, > > > > I have been wondering why doesn open-vswitch code links the entire > > "lib/libopenvswitch.la" into every binary in the code. > > > > Isn't that very in-efficient? Shouldn't we create separate libraries based > > on some logical divide, and then link the libraries based on the need. > > > > We should have created the following libraries in the source code. > > 1) LACP.a. > > 2) Sflow.a > > 3) Vlog.a > > 4) Ovsdb_client.a > > 5) Etc.. > > > > That will give flexibility to developers who want to create their own tools > > based on open-vswitch code. > > > > With the current design, a developer has to link almost the entire > > "lib/libopenvswitch.la" even in a small tool which uses ovsdb. > > > > Can someone through some history behind this design. > > > > If there is no specific reason, can I separate these things into small > > logical libraries and submit the patch? > > > > Regards > > Sreedhar > > _ > > From: Papudippu, Sreedhar Reddy > > Sent: Monday, February 09, 2015 3:10 PM > > To: dev@openvswitch.org > > Subject: ovsdb-idl > > > > > > Hello all, > > > > I was wondering why "ovsdb-idl" client API code is not made as a separate > > independent library. > > > > Assume if someone wants to write a new client for the ovsdb-idl, how will > > he/she link the code to the source library? > > How will he/she get the get the header file definitions? > > > > Regards > > Sreedhar > > > > ___ > > 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] ovsdb-idl
Do you see symbol conflicts? If not, then there's no real problem--the linker will discard the unused object files. On Thu, Feb 12, 2015 at 04:08:55AM +, Papudippu, Sreedhar Reddy wrote: > Hi Ben, > > I am trying to write few applications which are pure clients to OVSDB. I need > to link with OVSDB-IDL. > Currently the only way I can link with ovsdb-idl is by linking the with > lib/libopenvswitch.la > > Currently lib/libopenvswitch.la has sFlow, LACP, netdev-provider etc code > together. > When I link my binary with lib/libopenvswitch.la, then I carry over all the > above code pieces, which I am not interested in. > > That's why I want pure ovsdb-idl as a separate library. > > Regards > Sreedhar > > -Original Message- > From: Ben Pfaff [mailto:b...@nicira.com] > Sent: Wednesday, February 11, 2015 9:41 PM > To: Papudippu, Sreedhar Reddy > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] ovsdb-idl > > What kind of problems do you have with the rest of the library? Maybe we > should focus on that. > > On Thu, Feb 12, 2015 at 02:56:15AM +, Papudippu, Sreedhar Reddy wrote: > > Hi Ben, > > > > I do understand that making it as a Shared library brings in lot of > > troubles, due to the decoupling. > > But I am trying to make it as Static library (ovsdb-idl.a), so that if an > > external tool/application use the Ovsdb-ild library without carrying the > > rest of the baggage from open-switch/lib/*. > > > > If making the OVSDB-IDL code as a seperate static library is acceptable I > > can submit a patch for that. > > > > Regards > > Sreedhar > > > > -Original Message- > > From: Ben Pfaff [mailto:b...@nicira.com] > > Sent: Wednesday, February 11, 2015 6:55 PM > > To: Papudippu, Sreedhar Reddy > > Cc: dev@openvswitch.org > > Subject: Re: [ovs-dev] ovsdb-idl > > > > It's difficult to design and maintain a shared library with a stable public > > API and ABI. No one has done the work yet. > > > > On Tue, Feb 10, 2015 at 07:25:47PM +, Papudippu, Sreedhar Reddy wrote: > > > Hello all, > > > > > > I have been wondering why doesn open-vswitch code links the entire > > > "lib/libopenvswitch.la" into every binary in the code. > > > > > > Isn't that very in-efficient? Shouldn't we create separate libraries > > > based on some logical divide, and then link the libraries based on the > > > need. > > > > > > We should have created the following libraries in the source code. > > > 1) LACP.a. > > > 2) Sflow.a > > > 3) Vlog.a > > > 4) Ovsdb_client.a > > > 5) Etc.. > > > > > > That will give flexibility to developers who want to create their own > > > tools based on open-vswitch code. > > > > > > With the current design, a developer has to link almost the entire > > > "lib/libopenvswitch.la" even in a small tool which uses ovsdb. > > > > > > Can someone through some history behind this design. > > > > > > If there is no specific reason, can I separate these things into small > > > logical libraries and submit the patch? > > > > > > Regards > > > Sreedhar > > > _ > > > From: Papudippu, Sreedhar Reddy > > > Sent: Monday, February 09, 2015 3:10 PM > > > To: dev@openvswitch.org > > > Subject: ovsdb-idl > > > > > > > > > Hello all, > > > > > > I was wondering why "ovsdb-idl" client API code is not made as a separate > > > independent library. > > > > > > Assume if someone wants to write a new client for the ovsdb-idl, how will > > > he/she link the code to the source library? > > > How will he/she get the get the header file definitions? > > > > > > Regards > > > Sreedhar > > > > > > ___ > > > 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] mac-learning: Implement per-port MAC learning fairness.
In "MAC flooding", an attacker transmits an overwhelming number of frames
with unique Ethernet source address on a switch port. The goal is to
force the switch to evict all useful MAC learning table entries, so that
its behavior degenerates to that of a hub, flooding all traffic. In turn,
that allows an attacker to eavesdrop on the traffic of other hosts attached
to the switch, with all the risks that that entails.
Before this commit, the Open vSwitch "normal" action that implements its
standalone switch behavior (and that can be used by OpenFlow controllers
as well) was vulnerable to MAC flooding attacks. This commit fixes the
problem by implementing per-port fairness for MAC table entries: when
the MAC table is at its maximum size, MAC table eviction always deletes an
entry from the port with the most entries. Thus, MAC entries will never
be evicted from ports with only a few entries if a port with a huge number
of entries exists.
Controllers could introduce their own MAC flooding vulnerabilities into
OVS. For a controller that adds destination MAC based flows to an OpenFlow
flow table as a reaction to "packet-in" events, such a bug, if it exists,
would be in the controller code itself and would need to be fixed in the
controller. For a controller that relies on the Open vSwitch "learn"
action to add destination MAC based flows, Open vSwitch has existing
support for eviction policy similar to that implemented in this commit
through the "groups" column in the Flow_Table table documented in
ovs-vswitchd.conf.db(5); we recommend that users of "learn" not already
familiar with eviction groups to read that documentation.
In addition to implementation of per-port MAC learning fairness,
this commit includes some closely related changes:
- Access to client-provided "port" data in struct mac_entry
is now abstracted through helper functions, which makes it
easier to ensure that the per-port data structures are maintained
consistently.
- The mac_learning_changed() function, which had become trivial,
vestigial, and confusing, was removed. Its functionality was folded
into the new function mac_entry_set_port().
- Many comments were added and improved; there had been a lot of
comment rot in previous versions.
Reported-by: "Ronny L. Bull - bullrl"
Reported-at:
http://www.irongeek.com/i.php?page=videos/derbycon4/t314-exploring-layer-2-network-security-in-virtualized-environments-ronny-l-bull-dr-jeanna-n-matthews
Signed-off-by: Ben Pfaff
---
AUTHORS | 1 +
NEWS | 2 +
lib/learning-switch.c| 34 --
lib/mac-learning.c | 143 ---
lib/mac-learning.h | 122
ofproto/ofproto-dpif-xlate.c | 16 ++---
ofproto/ofproto-dpif.c | 12 ++--
tests/ofproto-dpif.at| 66
8 files changed, 330 insertions(+), 66 deletions(-)
diff --git a/AUTHORS b/AUTHORS
index 1903423..8b833dd 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -307,6 +307,7 @@ Roger Leigh rle...@codelibre.net
Rogério Vinhal Nunes
Roman Sokolkov rsokol...@gmail.com
Ronaldo A. Ferreira ronal...@cs.princeton.edu
+Ronny L. Bull bul...@clarkson.edu
Sander Eikelenboom li...@eikelenboom.it
Saul St. John sstj...@cs.wisc.edu
Scott Hendricks shendri...@nicira.com
diff --git a/NEWS b/NEWS
index adfa1d1..2b0c347 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,7 @@
Post-v2.3.0
-
+ - The MAC learning feature now includes per-port fairness to mitigate
+ MAC flooding attacks.
- New support for a "conjunctive match" OpenFlow extension, which
allows constructing OpenFlow matches of the form "field1 in
{a,b,c...} AND field2 in {d,e,f...}" and generalizations. For details,
diff --git a/lib/learning-switch.c b/lib/learning-switch.c
index 1423ac4..d03e52e 100644
--- a/lib/learning-switch.c
+++ b/lib/learning-switch.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014 Nicira, Inc.
+ * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -105,6 +105,13 @@ static enum ofperr process_switch_features(struct lswitch
*,
static void process_packet_in(struct lswitch *, const struct ofp_header *);
static void process_echo_request(struct lswitch *, const struct ofp_header *);
+static ofp_port_t get_mac_entry_ofp_port(const struct mac_learning *ml,
+ const struct mac_entry *)
+OVS_REQ_RDLOCK(ml->rwlock);
+static void set_mac_entry_ofp_port(struct mac_learning *ml,
+ struct mac_entry *, ofp_port_t)
+OVS_REQ_WRLOCK(ml->rwlock);
+
/* Creates and returns a new learning switch whose confi
