[ovs-dev] [PATCH] ofproto: Add del-flow based on table-id tests

2012-10-01 Thread Simon Horman 
Signed-off-by: Simon Horman 
---
 tests/ofproto.at |   32 
 1 file changed, 32 insertions(+)

diff --git a/tests/ofproto.at b/tests/ofproto.at
index fb82e01..455077b 100644
--- a/tests/ofproto.at
+++ b/tests/ofproto.at
@@ -362,6 +362,38 @@ NXST_FLOW reply:
 OVS_VSWITCHD_STOP
 AT_CLEANUP
 
+AT_SETUP([ofproto - del flows based on table id])
+OVS_VSWITCHD_START
+AT_CHECK([ovs-ofctl add-flow br0 cookie=0x1,in_port=1,actions=1])
+AT_CHECK([ovs-ofctl add-flow br0 cookie=0x2,in_port=2,table=1,actions=1])
+AT_CHECK([ovs-ofctl dump-flows br0 | ofctl_strip | sort], [0], [dnl
+ cookie=0x1, in_port=1 actions=output:1
+ cookie=0x2, table=1, in_port=2 actions=output:1
+NXST_FLOW reply:
+])
+AT_CHECK([ovs-ofctl del-flows br0 table=0])
+AT_CHECK([ovs-ofctl dump-flows br0 | ofctl_strip | sort], [0], [dnl
+ cookie=0x2, table=1, in_port=2 actions=output:1
+NXST_FLOW reply:
+])
+AT_CHECK([ovs-ofctl del-flows br0 table=1])
+AT_CHECK([ovs-ofctl dump-flows br0 | ofctl_strip | sort], [0], [dnl
+NXST_FLOW reply:
+])
+AT_CHECK([ovs-ofctl add-flow br0 cookie=0x1,in_port=1,actions=1])
+AT_CHECK([ovs-ofctl add-flow br0 cookie=0x2,in_port=2,table=1,actions=1])
+AT_CHECK([ovs-ofctl dump-flows br0 | ofctl_strip | sort], [0], [dnl
+ cookie=0x1, in_port=1 actions=output:1
+ cookie=0x2, table=1, in_port=2 actions=output:1
+NXST_FLOW reply:
+])
+AT_CHECK([ovs-ofctl del-flows br0])
+AT_CHECK([ovs-ofctl dump-flows br0 | ofctl_strip | sort], [0], [dnl
+NXST_FLOW reply:
+])
+OVS_VSWITCHD_STOP
+AT_CLEANUP
+
 AT_SETUP([ofproto - flow table configuration])
 OVS_VSWITCHD_START
 # Check the default configuration.
-- 
1.7.10.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] ofp-util: Use table_id in OF1.2 Flow Remove Messages

2012-10-01 Thread Simon Horman 
Previously this field was ignored on decode and
set to zero on encode

Also add OFPTT_ALL and OFPTT_MAX and use OFPTT_ALL in the one location
where it seems appropriate.

Signed-off-by: Simon Horman 
---
 include/openflow/openflow-1.1.h |9 +
 lib/ofp-print.c |4 
 lib/ofp-util.c  |8 +---
 lib/ofp-util.h  |1 +
 ofproto/ofproto.c   |1 +
 tests/ofp-print.at  |2 +-
 6 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/include/openflow/openflow-1.1.h b/include/openflow/openflow-1.1.h
index 9785db4..8cead55 100644
--- a/include/openflow/openflow-1.1.h
+++ b/include/openflow/openflow-1.1.h
@@ -771,4 +771,13 @@ struct ofp11_flow_removed {
 };
 OFP_ASSERT(sizeof(struct ofp11_flow_removed) == 40);
 
+enum ofp_table {
+/* Last usable table number. */
+OFPTT_MAX = 0xfe,
+/* Fake tables. */
+OFPTT_ALL = 0xff
+/* Wildcard table used for table config, flow stats and flow deletes. */
+};
+
+
 #endif /* openflow/openflow-1.1.h */
diff --git a/lib/ofp-print.c b/lib/ofp-print.c
index 6789625..7682b7f 100644
--- a/lib/ofp-print.c
+++ b/lib/ofp-print.c
@@ -843,6 +843,10 @@ ofp_print_flow_removed(struct ds *string, const struct 
ofp_header *oh)
 ds_put_format(string, " reason=%s",
   ofp_flow_removed_reason_to_string(fr.reason));
 
+if (fr.table_id) {
+ds_put_format(string, " table_id=%"PRIu8, fr.table_id);
+}
+
 if (fr.cookie != htonll(0)) {
 ds_put_format(string, " cookie:0x%"PRIx64, ntohll(fr.cookie));
 }
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index c78199f..4417e2c 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -1249,7 +1249,7 @@ ofputil_decode_flow_mod(struct ofputil_flow_mod *fm,
 fm->table_id = command >> 8;
 } else {
 fm->command = command;
-fm->table_id = 0xff;
+fm->table_id = OFPTT_ALL;
 }
 }
 
@@ -1913,7 +1913,7 @@ ofputil_decode_flow_removed(struct ofputil_flow_removed 
*fr,
 fr->priority = ntohs(ofr->priority);
 fr->cookie = ofr->cookie;
 fr->reason = ofr->reason;
-/* XXX: ofr->table_id is ignored */
+fr->table_id = ofr->table_id;
 fr->duration_sec = ntohl(ofr->duration_sec);
 fr->duration_nsec = ntohl(ofr->duration_nsec);
 fr->idle_timeout = ntohs(ofr->idle_timeout);
@@ -1929,6 +1929,7 @@ ofputil_decode_flow_removed(struct ofputil_flow_removed 
*fr,
 fr->priority = ntohs(ofr->priority);
 fr->cookie = ofr->cookie;
 fr->reason = ofr->reason;
+fr->table_id = 0;
 fr->duration_sec = ntohl(ofr->duration_sec);
 fr->duration_nsec = ntohl(ofr->duration_nsec);
 fr->idle_timeout = ntohs(ofr->idle_timeout);
@@ -1952,6 +1953,7 @@ ofputil_decode_flow_removed(struct ofputil_flow_removed 
*fr,
 fr->priority = ntohs(nfr->priority);
 fr->cookie = nfr->cookie;
 fr->reason = nfr->reason;
+fr->table_id = 0;
 fr->duration_sec = ntohl(nfr->duration_sec);
 fr->duration_nsec = ntohl(nfr->duration_nsec);
 fr->idle_timeout = ntohs(nfr->idle_timeout);
@@ -1985,7 +1987,7 @@ ofputil_encode_flow_removed(const struct 
ofputil_flow_removed *fr,
 ofr->cookie = fr->cookie;
 ofr->priority = htons(fr->priority);
 ofr->reason = fr->reason;
-ofr->table_id = 0;
+ofr->table_id = fr->table_id;
 ofr->duration_sec = htonl(fr->duration_sec);
 ofr->duration_nsec = htonl(fr->duration_nsec);
 ofr->idle_timeout = htons(fr->idle_timeout);
diff --git a/lib/ofp-util.h b/lib/ofp-util.h
index 38e7b02..80de72d 100644
--- a/lib/ofp-util.h
+++ b/lib/ofp-util.h
@@ -243,6 +243,7 @@ struct ofputil_flow_removed {
 uint16_t priority;
 ovs_be64 cookie;
 uint8_t reason; /* One of OFPRR_*. */
+uint8_t table_id;
 uint32_t duration_sec;
 uint32_t duration_nsec;
 uint16_t idle_timeout;
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index 7c92d71..52203fd 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -3225,6 +3225,7 @@ ofproto_rule_send_removed(struct rule *rule, uint8_t 
reason)
 fr.priority = rule->cr.priority;
 fr.cookie = rule->flow_cookie;
 fr.reason = reason;
+fr.table_id = rule->table_id;
 calc_flow_duration__(rule->created, time_msec(),
  &fr.duration_sec, &fr.duration_nsec);
 fr.idle_timeout = rule->idle_timeout;
diff --git a/tests/ofp-print.at b/tests/ofp-print.at
index c2eb002..fee3d28 100644
--- a/tests/ofp-print.at
+++ b/tests/ofp-print.at
@@ -376,7 +376,7 @@ AT_CHECK([ovs-ofctl ofp-print "\
 80 00 01 05 00 00 00 01 00 98 96 80 00 3c 00 78 \
 00 00 00 00 00 12 d6 87 00 00 00 00 6f 68 ba 66 \
 00 01 00 0a 80 00 0c 02 10 09 00 00 00 00 00 00"], [0], [dnl
-OFPT_FLOW_REMOVED (OF1.2) (xid=0x0): dl_vlan=9 reason=hard 
cookie:0xfedcba9876543210 duration1.01s idle60 hard1

[ovs-dev] [PATCH] vswitch: allow to specify ofport when creating port

2012-10-01 Thread Isaku Yamahata 
For stable bridge configuration, sometimes it is desirable to be able to
add-port with port number specified.
This patch implements it and it can be done by setting ofport column of 
Interface
table like

  ovs-vsctl add-port s1 eth2 -- set Interface eth2 ofport=10

Signed-off-by: Isaku Yamahata 
---
 ofproto/ofproto-dpif.c |2 +-
 ofproto/ofproto.c  |2 +-
 tests/ovs-vsctl.at |   29 +
 vswitchd/bridge.c  |   39 +++
 4 files changed, 58 insertions(+), 14 deletions(-)

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index dcdd8f2..0bba0ec 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -2531,7 +2531,7 @@ static int
 port_add(struct ofproto *ofproto_, struct netdev *netdev, uint16_t *ofp_portp)
 {
 struct ofproto_dpif *ofproto = ofproto_dpif_cast(ofproto_);
-uint16_t odp_port = UINT16_MAX;
+uint16_t odp_port = ofp_port_to_odp_port(*ofp_portp);
 int error;
 
 error = dpif_port_add(ofproto->dpif, netdev, &odp_port);
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index b87b6e7..25b1824 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -1353,7 +1353,7 @@ int
 ofproto_port_add(struct ofproto *ofproto, struct netdev *netdev,
  uint16_t *ofp_portp)
 {
-uint16_t ofp_port;
+uint16_t ofp_port = ofp_portp ? *ofp_portp : OFPP_NONE;
 int error;
 
 error = ofproto->ofproto_class->port_add(ofproto, netdev, &ofp_port);
diff --git a/tests/ovs-vsctl.at b/tests/ovs-vsctl.at
index e903619..00e37cc 100644
--- a/tests/ovs-vsctl.at
+++ b/tests/ovs-vsctl.at
@@ -1096,3 +1096,32 @@ AT_CHECK([RUN_OVS_VSCTL(
[-- list Queue])], [0], [], [], [OVS_VSCTL_CLEANUP])
 OVS_VSCTL_CLEANUP
 AT_CLEANUP
+
+dnl --
+AT_BANNER([ovs-vsctl unit tests --- add-port with port no specified])
+
+AT_SETUP([add-br a, add-port a a1, set Interface a ofport=10])
+AT_KEYWORDS([ovs-vsctl port-no])
+OVS_VSCTL_SETUP
+AT_CHECK([RUN_OVS_VSCTL([add-br a])], [0], [], [], [OVS_VSCTL_CLEANUP])
+CHECK_BRIDGES([a, a, 0])
+AT_CHECK([RUN_OVS_VSCTL([add-port a a0])], [0], [], [], [OVS_VSCTL_CLEANUP])
+CHECK_BRIDGES([a, a, 0])
+CHECK_PORTS([a], [a0])
+CHECK_IFACES([a], [a0])
+AT_CHECK([RUN_OVS_VSCTL(get Interface a0 ofport)], [0], [[[]
+]], [], [OVS_VSCTL_CLEANUP])
+AT_CHECK([RUN_OVS_VSCTL([del-port a a0])], [0], [], [], [OVS_VSCTL_CLEANUP])
+
+AT_CHECK([RUN_OVS_VSCTL_TOGETHER(
+   [add-port a a1],
+   [set Interface a1 ofport=10])], [0], [
+
+], [], [OVS_VSCTL_CLEANUP])
+CHECK_PORTS([a], [a1])
+CHECK_IFACES([a], [a1])
+AT_CHECK([RUN_OVS_VSCTL(get Interface a1 ofport)], [0], [10
+], [], [OVS_VSCTL_CLEANUP])
+AT_CHECK([RUN_OVS_VSCTL([del-port a a1])], [0], [], [], [OVS_VSCTL_CLEANUP])
+OVS_VSCTL_CLEANUP
+AT_CLEANUP
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 940e5e7..e98ac57 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -65,6 +65,8 @@ COVERAGE_DEFINE(bridge_reconfigure);
 struct if_cfg {
 struct hmap_node hmap_node; /* Node in bridge's if_cfg_todo. */
 const struct ovsrec_interface *cfg; /* Interface record. */
+int64_t ofport; /* requested ofport. OFPP_NONE means
+   auto-allocate ofport */
 const struct ovsrec_port *parent;   /* Parent port record. */
 };
 
@@ -225,7 +227,8 @@ static bool mirror_configure(struct mirror *);
 static void mirror_refresh_stats(struct mirror *);
 
 static void iface_configure_lacp(struct iface *, struct lacp_slave_settings *);
-static bool iface_create(struct bridge *, struct if_cfg *, int ofp_port);
+static bool iface_create(struct bridge *, struct if_cfg *,
+ int ofp_port, bool allocate_port);
 static const char *iface_get_type(const struct ovsrec_interface *,
   const struct ovsrec_bridge *);
 static void iface_destroy(struct iface *);
@@ -495,7 +498,7 @@ bridge_reconfigure_ofp(void)
 struct if_cfg *if_cfg, *next;
 
 HMAP_FOR_EACH_SAFE (if_cfg, next, hmap_node, &br->if_cfg_todo) {
-iface_create(br, if_cfg, -1);
+iface_create(br, if_cfg, if_cfg->ofport, true);
 time_refresh();
 if (time_msec() >= deadline) {
 return false;
@@ -1205,9 +1208,14 @@ bridge_refresh_one_ofp_port(struct bridge *br,
  * and add it.  If that's successful, we'll keep it.  Otherwise, we'll
  * delete it and later try to re-add it. */
 struct if_cfg *if_cfg = if_cfg_lookup(br, name);
+bool allocate_port = false;
+if (ofp_port < 0) {
+ofp_port = OFPP_NONE;
+allocate_port = true;
+}
 return (if_cfg
 && !strcmp(type, iface_get_type(if_cfg->cfg, br->cfg))
-&& iface_create(br, if_cfg, ofp_port));
+&& iface_create(br, if_cfg, ofp_port, allocate_port));
 }
 }
 
@@ -1

Re: [ovs-dev] [PATCH 2/4] dpif-netdev: Add SCTP support

2012-10-01 Thread Joe Stringer 
On 28 September 2012 04:53, Ben Pfaff  wrote:
> "sparse" reports a potential byte-swapping error:

I would imagine this is because the CRC32C implementation I introduced
in patch #1 purports to calculate checksums in HBO. Perhaps that
should be modified to use ovs_be32?

> It looks to me like the SCTP checksum is getting computed across the
> entire packet, including the Ethernet header.  I doubt that that can
> be correct.  Can you take a look?

I wasn't 100% confident that I understood how the function was
interacting with the ofpbuf struct, so it's likely I've simply got it
wrong. With a fresh look it seems like I should actually be using *sh
to calculate the checksum. I'll make the modification for round two.

> Also, for IP-like checksums we're able to do an incremental update of
> the checksum, instead of a wholesale replacement, which means that any
> error in the original checksum will be retained, so that the packet
> will (correctly) be discarded when it arrives at its destination.  To
> preserve that property, I think we'd have to check the checksum before
> we update it.  We could do something like this:
>
> ...
>
> so that the behavior is quite similar to that for TCP and UDP,
> although much more expensive.

I see. I wasn't sure if CRC32c was IP-like enough (no reason, I just
haven't studied the CRCs). I also misinterpreted the reasoning for
updating the checksum.

Do we currently have code that triggers this? I take it that this type
of recalculation is required when we modify the packet, eg set-field
action. What I'd like to know is how I might test that the behaviour
is correct.

One idea perhaps would be to place OVS between two hosts and make it
change the destination port on flows in one direction, then using
lksctp, see whether the hosts continue to communicate correctly. This
has been my general approach to testing this patchset. The downside is
that it's a lot of overhead to set up, unlike the autotests.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 3/4] dpif-linux: Add SCTP support

2012-10-01 Thread Joe Stringer 
On 28 September 2012 04:53, Ben Pfaff  wrote:
> On Fri, Aug 31, 2012 at 10:44:28PM +1200, Joe Stringer wrote:
>> Signed-off-by: Joe Stringer 
>
> I think this one needs a review from Jesse.

This will have the same checksum calculation errors as patch #2:
http://openvswitch.org/pipermail/dev/2012-September/021491.html
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 4/4] ofp-util: Support matching on SCTP src, dst ports

2012-10-01 Thread Joe Stringer 
Cheers. This patch no longer applies cleanly on master, so I'll tidy
that up and update NEWS when I repost the set.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] "brctl show" doesn't list attached interfaces

2012-10-01 Thread Tadaaki Nagao 
Hi Pravin,

In "Re: [ovs-dev] "brctl show" doesn't list attached interfaces",
Pravin Shelar  wrote:
> On Thu, Sep 27, 2012 at 8:18 PM, Tadaaki Nagao  
> wrote:
> > Hi,
> >
> > In "Re: [ovs-dev] "brctl show" doesn't list attached interfaces",
> > Jesse Gross  wrote:
> >> I think it's the opposite problem - that OVS ports aren't appearing in
> >> brctl output.  There's a bug with namespaces on certain kernels when
> >> populating the sysfs entries that Pravin ran into so we don't do that
> >> on the theory that missing entries are better than crashing.
> >
> > In datapath/dp_sysfs_dp.c:ovs_dp_sysfs_add_dp() there's a similar NULL
> > check with the same "could panic" comment, which makes sense to me because
> > sysfs_create_group() is actually called after the check.
> >
> > 8 > #ifdef CONFIG_NET_NS
> > /* Due to bug in 2.6.32 kernel, sysfs_create_group() could panic
> >  * in other namespace than init_net. Following check is to avoid 
> > it. */
> > if (!kobj->sd)
> > return -ENOENT;
> > #endif
> > /* Create /sys/class/net//bridge directory. */
> > err = sysfs_create_group(kobj, &bridge_group);
> > 8 >
> > OTOH, after the check in datapath/dp_sysfs_if.c:ovs_dp_sysfs_add_if()
> > there's no call to sysfs_create_group() as I mentioned in the first mail.
> > And that made me uncertain what the check is actually meant for...
> >
> right, there is no call to sysfs_crate_grp() when adding a interface,
> need to fix comment.
> But it does panic on 2.6.32 while creating sysfs hierarchy in
> sysfs_create_dir(). I am not sure which kernel does fixes this issue.

Thank you for your comments!

I've finally managed to create a test environment on LXC + CentOS 6.3
(kernel 2.6.32-279.9.1.el6.x86_64) and could reproduce a panic when
commenting out the NULL check in ovs_dp_sysfs_add_if().

> I will see if we could have better check here.

If there's something I can do here, please let me know.

> Thanks,
> Pravin.

Thanks,
Tadaaki Nagao 
Stratosphere Inc.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Check out my music

2012-10-01 Thread HUSTLEMANN 

http://cache.reverbnation.com/widgets/swf/48/pro_widget.swf?id=artist_2782324&posted_by=artist_2782324&skin_id=PWFS5010&background_color=EE&border_color=00&auto_play=false&shuffle=false";>http://cache.reverbnation.com/widgets/swf/48/pro_widget.swf?id=artist_2782324&posted_by=artist_2782324&skin_id=PWFS5010&background_color=EE&border_color=00&auto_play=false&shuffle=false"; type="application/x-shockwave-flash" allowscriptaccess="always" allowNetworking="all" allowfullscreen="true" wmode="opaque" 
flashvars="id=artist_2782324&posted_by=artist_2782324&skin_id=PWFS5010&background_color=EE&border_color=00&auto_play=false&shuffle=false" quality="best" width="434" height="326">
http://www.reverbnation.com/widgets/trk/48/artist_2782324/artist_2782324/t.gif"; />http://ib.adnxs.com/seg?add=393113&t=2"/>http://ib.adnxs.com/seg?add=405193&t=2"/>


THANK YOU FOR YOUR TIME...

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 0/2] Add flow-based tunneling support

2012-10-01 Thread Kyle Mestery 
These patches build on the first two patches which Simon Horman sent out in
May to move Open vSwitch towards flow-based tunneling. The first patche adds
a tun_key, deprecating the tun_id member of the ovs_skb_cb struct. This patche
retain compatibilty with existing tunneling, but once the userspace code is
submitted, this will be deprecated. The second patch makes an attempt at adding
the new tun_key structure into the flow matching logic in the kernel.

Kyle Mestery (2):
  This is a first pass at providing a tun_key which can be used as
the basis for flow-based tunnelling. The tun_key includes and
replaces the tun_id in both struct ovs_skb_cb and struct
sw_tun_key.
  Move struct ovs_key_ipv4_tunnel out of struct sw_flow_key and into   
 struct sw_flow. This allows it to "float" and be used for matching
only when needed. Modify the matching code in
ovs_flow_tbl_lookup() to match on the tunnel header if it's
set.

 NEWS|  3 ++
 datapath/actions.c  | 25 +++--
 datapath/datapath.c | 37 +--
 datapath/datapath.h |  6 ++-
 datapath/flow.c | 88 +---
 datapath/flow.h | 25 -
 datapath/tunnel.c   | 89 +++--
 datapath/tunnel.h   | 14 ++-
 datapath/vport-capwap.c | 12 +++---
 datapath/vport-gre.c| 15 
 datapath/vport.c|  2 +-
 include/linux/openvswitch.h | 13 ++-
 lib/dpif-netdev.c   |  1 +
 lib/odp-util.c  | 15 +++-
 lib/odp-util.h  |  3 +-
 15 files changed, 252 insertions(+), 96 deletions(-)

-- 
1.7.11.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 2/2] Add flow matching for tunnel keys

2012-10-01 Thread Kyle Mestery 
Move struct ovs_key_ipv4_tunnel out of struct
sw_flow_key and into struct sw_flow. This allows it to
"float" and be used for matching only when needed.
Modify the matching code in ovs_flow_tbl_lookup() to
match on the tunnel header if it's set.

---
V2: Remove lib/odp-util.c changes in favor of using the version from
Jesse's changeset.

Signed-off-by: Kyle Mestery 
---
 datapath/actions.c  |  1 +
 datapath/datapath.c | 29 ++--
 datapath/datapath.h |  1 +
 datapath/flow.c | 65 +
 datapath/flow.h | 17 +++---
 datapath/tunnel.c   |  5 +++--
 6 files changed, 72 insertions(+), 46 deletions(-)

diff --git a/datapath/actions.c b/datapath/actions.c
index a70cde8..063d3af 100644
--- a/datapath/actions.c
+++ b/datapath/actions.c
@@ -288,6 +288,7 @@ static int output_userspace(struct datapath *dp, struct 
sk_buff *skb,
 
upcall.cmd = OVS_PACKET_CMD_ACTION;
upcall.key = &OVS_CB(skb)->flow->key;
+   upcall.tun_key = &OVS_CB(skb)->flow->tun_key;
upcall.userdata = NULL;
upcall.pid = 0;
 
diff --git a/datapath/datapath.c b/datapath/datapath.c
index d8a198e..845494c 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -313,10 +313,11 @@ void ovs_dp_process_received_packet(struct vport *p, 
struct sk_buff *skb)
 
if (!OVS_CB(skb)->flow) {
struct sw_flow_key key;
+   struct ovs_key_ipv4_tunnel tun_key;
int key_len;
 
/* Extract flow from 'skb' into 'key'. */
-   error = ovs_flow_extract(skb, p->port_no, &key, &key_len);
+   error = ovs_flow_extract(skb, p->port_no, &key, &tun_key, 
&key_len);
if (unlikely(error)) {
kfree_skb(skb);
return;
@@ -324,12 +325,13 @@ void ovs_dp_process_received_packet(struct vport *p, 
struct sk_buff *skb)
 
/* Look up flow. */
flow = ovs_flow_tbl_lookup(rcu_dereference(dp->table),
-  &key, key_len);
+  &key, &tun_key, key_len);
if (unlikely(!flow)) {
struct dp_upcall_info upcall;
 
upcall.cmd = OVS_PACKET_CMD_MISS;
upcall.key = &key;
+   upcall.tun_key = &tun_key;
upcall.userdata = NULL;
upcall.pid = p->upcall_pid;
ovs_dp_upcall(dp, skb, &upcall);
@@ -492,7 +494,7 @@ static int queue_userspace_packet(struct net *net, int 
dp_ifindex,
upcall->dp_ifindex = dp_ifindex;
 
nla = nla_nest_start(user_skb, OVS_PACKET_ATTR_KEY);
-   ovs_flow_to_nlattrs(upcall_info->key, user_skb);
+   ovs_flow_to_nlattrs(upcall_info->key, upcall_info->tun_key, user_skb);
nla_nest_end(user_skb, nla);
 
if (upcall_info->userdata)
@@ -787,13 +789,13 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb, 
struct genl_info *info)
if (IS_ERR(flow))
goto err_kfree_skb;
 
-   err = ovs_flow_extract(packet, -1, &flow->key, &key_len);
+   err = ovs_flow_extract(packet, -1, &flow->key, &flow->tun_key, 
&key_len);
if (err)
goto err_flow_put;
 
err = ovs_flow_metadata_from_nlattrs(&flow->key.phy.priority,
 &flow->key.phy.in_port,
-&flow->key.tun.tun_key,
+&flow->tun_key,
 a[OVS_PACKET_ATTR_KEY]);
if (err)
goto err_flow_put;
@@ -922,7 +924,7 @@ static int ovs_flow_cmd_fill_info(struct sw_flow *flow, 
struct datapath *dp,
nla = nla_nest_start(skb, OVS_FLOW_ATTR_KEY);
if (!nla)
goto nla_put_failure;
-   err = ovs_flow_to_nlattrs(&flow->key, skb);
+   err = ovs_flow_to_nlattrs(&flow->key, &flow->tun_key, skb);
if (err)
goto error;
nla_nest_end(skb, nla);
@@ -1016,6 +1018,7 @@ static int ovs_flow_cmd_new_or_set(struct sk_buff *skb, 
struct genl_info *info)
struct nlattr **a = info->attrs;
struct ovs_header *ovs_header = info->userhdr;
struct sw_flow_key key;
+   struct ovs_key_ipv4_tunnel tun_key;
struct sw_flow *flow;
struct sk_buff *reply;
struct datapath *dp;
@@ -1027,7 +1030,7 @@ static int ovs_flow_cmd_new_or_set(struct sk_buff *skb, 
struct genl_info *info)
error = -EINVAL;
if (!a[OVS_FLOW_ATTR_KEY])
goto error;
-   error = ovs_flow_from_nlattrs(&key, &key_len, a[OVS_FLOW_ATTR_KEY]);
+   error = ovs_flow_from_nlattrs(&key, &tun_key, &key_len, 
a[OVS_FLOW_ATTR_KEY]);
if (error)
goto error;
 
@@ -1047,7 +1050,7 @@ static int ovs_flow_cmd_new_or_set(struct sk_buff *skb, 
struc

[ovs-dev] [PATCH 1/2] Add support for tun_key to OVS datapath

2012-10-01 Thread Kyle Mestery 
This is a first pass at providing a tun_key which can be
used as the basis for flow-based tunnelling. The
tun_key includes and replaces the tun_id in both struct
ovs_skb_cb and struct sw_tun_key.

This patch allows all existing tun_id behaviour to still work. Existing
users of tun_id are redirected to tun_key->tun_id to retain compatibility.
However, when the userspace code is updated to make use of the new tun_key,
the old behaviour will be deprecated and removed.

NOTE: With these changes, the tunneling code no longer assumes input and
output keys are symmetric.  If they are not, PMTUD needs to be disabled
for tunneling to work.

Signed-off-by: Kyle Mestery 
Cc: Simon Horman 
Cc: Jesse Gross 
---
V5:
- Address another round of comments from Jesse.
V4:
- Address 2 comments from Jesse:
  - When processing actions, if OVS_CB(skb)->tun_key is NULL, point it at one
on the stack temporarily. This goes away when we remove the ability to set
tun_id outside the scope of tun_key.
  - Move tun_key to the end of struct sw_flow_key.
V3:
- Fix issues found during review by Jesse.
- Add a NEWS entry around tunnel code no longer assuming symmetric input and
  output tunnel keys.

V2:
- Fix blank line addition/removal found by Simon.
- Fix hex printing output found by Simon.
---
 NEWS|  3 ++
 datapath/actions.c  | 24 ++---
 datapath/datapath.c | 10 +-
 datapath/datapath.h |  5 +--
 datapath/flow.c | 61 +++-
 datapath/flow.h | 12 ---
 datapath/tunnel.c   | 84 +++--
 datapath/tunnel.h   | 14 ++--
 datapath/vport-capwap.c | 12 +++
 datapath/vport-gre.c| 15 
 datapath/vport.c|  2 +-
 include/linux/openvswitch.h | 13 ++-
 lib/dpif-netdev.c   |  1 +
 lib/odp-util.c  | 15 +++-
 lib/odp-util.h  |  3 +-
 15 files changed, 202 insertions(+), 72 deletions(-)

diff --git a/NEWS b/NEWS
index 29fd9f3..ae831e3 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,8 @@
 post-v1.8.0
 
+- The tunneling code no longer assumes input and output keys are symmetric.
+  If they are not, PMTUD needs to be disabled for tunneling to work. Note
+  this only applies to flow-based keys.
 - FreeBSD is now a supported platform, thanks to code contributions from
   Gaetano Catalli, Ed Maste, and Giuseppe Lettieri.
 - ovs-bugtool: New --ovs option to report only OVS related information.
diff --git a/datapath/actions.c b/datapath/actions.c
index ec9b595..a70cde8 100644
--- a/datapath/actions.c
+++ b/datapath/actions.c
@@ -333,7 +333,8 @@ static int sample(struct datapath *dp, struct sk_buff *skb,
 }
 
 static int execute_set_action(struct sk_buff *skb,
-const struct nlattr *nested_attr)
+const struct nlattr *nested_attr,
+struct ovs_key_ipv4_tunnel *tun_key)
 {
int err = 0;
 
@@ -343,7 +344,21 @@ static int execute_set_action(struct sk_buff *skb,
break;
 
case OVS_KEY_ATTR_TUN_ID:
-   OVS_CB(skb)->tun_id = nla_get_be64(nested_attr);
+   if (OVS_CB(skb)->tun_key == NULL) {
+   /* If tun_key is NULL for this skb, assign it to
+* a value the caller passed in for action processing
+* and output. This can disappear once we drop support
+* for setting tun_id outside of tun_key.
+*/
+   memset(tun_key, 0, sizeof(struct ovs_key_ipv4_tunnel));
+   OVS_CB(skb)->tun_key = tun_key;
+   }
+
+   OVS_CB(skb)->tun_key->tun_id = nla_get_be64(nested_attr);
+   break;
+
+   case OVS_KEY_ATTR_IPV4_TUNNEL:
+   OVS_CB(skb)->tun_key = nla_data(nested_attr);
break;
 
case OVS_KEY_ATTR_ETHERNET:
@@ -377,6 +392,7 @@ static int do_execute_actions(struct datapath *dp, struct 
sk_buff *skb,
int prev_port = -1;
const struct nlattr *a;
int rem;
+   struct ovs_key_ipv4_tunnel tun_key;
 
for (a = attr, rem = len; rem > 0;
 a = nla_next(a, &rem)) {
@@ -407,7 +423,7 @@ static int do_execute_actions(struct datapath *dp, struct 
sk_buff *skb,
break;
 
case OVS_ACTION_ATTR_SET:
-   err = execute_set_action(skb, nla_data(a));
+   err = execute_set_action(skb, nla_data(a), &tun_key);
break;
 
case OVS_ACTION_ATTR_SAMPLE:
@@ -469,7 +485,7 @@ int ovs_execute_actions(struct datapath *dp, struct sk_buff 
*skb)
goto out_loop;
}
 
-   OVS_CB(skb)->tun_id = 0;
+   OVS_CB(skb)->tun_key = NULL;
error = do_execute_actions(dp, skb, acts

Re: [ovs-dev] [PATCH] ofproto: Add del-flow based on table-id tests

2012-10-01 Thread Ben Pfaff 
On Mon, Oct 01, 2012 at 04:24:21PM +0900, Simon Horman wrote:
> Signed-off-by: Simon Horman 

Applied to master, thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ofp-util: Use table_id in OF1.2 Flow Remove Messages

2012-10-01 Thread Ben Pfaff 
On Mon, Oct 01, 2012 at 04:51:49PM +0900, Simon Horman wrote:
> Previously this field was ignored on decode and
> set to zero on encode
> 
> Also add OFPTT_ALL and OFPTT_MAX and use OFPTT_ALL in the one location
> where it seems appropriate.
> 
> Signed-off-by: Simon Horman 

Thanks for adding this support.

Using a constant like OFPTT_ALL is a good idea, but it is more widely
useful than your patch shows; try "grep"ping for 255 and 0xff and you
will see more instances of its use for table IDs.  I'd rather try to
use it everywhere applicable, instead of just in one place, so I
dropped that change.

I think that it's a good idea to try to distinguish table 0 from
"message didn't have a table ID", so I changed the "default" value for
decode to 255, which isn't otherwise a valid value.

I also added a comment on the table_id member to reflect that.

I've appended what I'm applying.

Thank you!

--8<--cut here-->8--

From: Simon Horman 
Date: Mon, 1 Oct 2012 16:51:49 +0900
Subject: [PATCH] ofp-util: Use table_id in OF1.1 and OF1.2 Flow Remove Messages

Previously this field was ignored on decode and
set to zero on encode

Signed-off-by: Simon Horman 
[b...@nicira.com changed "missing" value, removed OFPTT_ALL]
Signed-off-by: Ben Pfaff 
---
 lib/ofp-print.c|4 
 lib/ofp-util.c |6 --
 lib/ofp-util.h |1 +
 ofproto/ofproto.c  |1 +
 tests/ofp-print.at |2 +-
 5 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/lib/ofp-print.c b/lib/ofp-print.c
index 6789625..9123f2f 100644
--- a/lib/ofp-print.c
+++ b/lib/ofp-print.c
@@ -843,6 +843,10 @@ ofp_print_flow_removed(struct ds *string, const struct 
ofp_header *oh)
 ds_put_format(string, " reason=%s",
   ofp_flow_removed_reason_to_string(fr.reason));
 
+if (fr.table_id != 255) {
+ds_put_format(string, " table_id=%"PRIu8, fr.table_id);
+}
+
 if (fr.cookie != htonll(0)) {
 ds_put_format(string, " cookie:0x%"PRIx64, ntohll(fr.cookie));
 }
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index c78199f..7edae87 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -1913,7 +1913,7 @@ ofputil_decode_flow_removed(struct ofputil_flow_removed 
*fr,
 fr->priority = ntohs(ofr->priority);
 fr->cookie = ofr->cookie;
 fr->reason = ofr->reason;
-/* XXX: ofr->table_id is ignored */
+fr->table_id = ofr->table_id;
 fr->duration_sec = ntohl(ofr->duration_sec);
 fr->duration_nsec = ntohl(ofr->duration_nsec);
 fr->idle_timeout = ntohs(ofr->idle_timeout);
@@ -1929,6 +1929,7 @@ ofputil_decode_flow_removed(struct ofputil_flow_removed 
*fr,
 fr->priority = ntohs(ofr->priority);
 fr->cookie = ofr->cookie;
 fr->reason = ofr->reason;
+fr->table_id = 255;
 fr->duration_sec = ntohl(ofr->duration_sec);
 fr->duration_nsec = ntohl(ofr->duration_nsec);
 fr->idle_timeout = ntohs(ofr->idle_timeout);
@@ -1952,6 +1953,7 @@ ofputil_decode_flow_removed(struct ofputil_flow_removed 
*fr,
 fr->priority = ntohs(nfr->priority);
 fr->cookie = nfr->cookie;
 fr->reason = nfr->reason;
+fr->table_id = 255;
 fr->duration_sec = ntohl(nfr->duration_sec);
 fr->duration_nsec = ntohl(nfr->duration_nsec);
 fr->idle_timeout = ntohs(nfr->idle_timeout);
@@ -1985,7 +1987,7 @@ ofputil_encode_flow_removed(const struct 
ofputil_flow_removed *fr,
 ofr->cookie = fr->cookie;
 ofr->priority = htons(fr->priority);
 ofr->reason = fr->reason;
-ofr->table_id = 0;
+ofr->table_id = fr->table_id;
 ofr->duration_sec = htonl(fr->duration_sec);
 ofr->duration_nsec = htonl(fr->duration_nsec);
 ofr->idle_timeout = htons(fr->idle_timeout);
diff --git a/lib/ofp-util.h b/lib/ofp-util.h
index 38e7b02..8ef2206 100644
--- a/lib/ofp-util.h
+++ b/lib/ofp-util.h
@@ -243,6 +243,7 @@ struct ofputil_flow_removed {
 uint16_t priority;
 ovs_be64 cookie;
 uint8_t reason; /* One of OFPRR_*. */
+uint8_t table_id;   /* 255 if message didn't include table ID. */
 uint32_t duration_sec;
 uint32_t duration_nsec;
 uint16_t idle_timeout;
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index 7c92d71..52203fd 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -3225,6 +3225,7 @@ ofproto_rule_send_removed(struct rule *rule, uint8_t 
reason)
 fr.priority = rule->cr.priority;
 fr.cookie = rule->flow_cookie;
 fr.reason = reason;
+fr.table_id = rule->table_id;
 calc_flow_duration__(rule->created, time_msec(),
  &fr.duration_sec, &fr.duration_nsec);
 fr.idle_timeout = rule->idle_timeout;
diff --git a/tests/ofp-print.at b/tests/ofp-print.at
index c2eb002..fee3d28 100644
--- a/tests/ofp-print.at
+++ b/tests/ofp-print.at
@@ -376,7 +376,7 @@ AT_CHECK([ovs-ofctl ofp-print "\
 80 00 01 05 00 00 00 01 00 98 96

Re: [ovs-dev] [PATCH] vswitch: allow to specify ofport when creating port

2012-10-01 Thread Ben Pfaff 
On Mon, Oct 01, 2012 at 05:35:19PM +0900, Isaku Yamahata wrote:
> For stable bridge configuration, sometimes it is desirable to be able to
> add-port with port number specified.
> This patch implements it and it can be done by setting ofport column of 
> Interface
> table like
> 
>   ovs-vsctl add-port s1 eth2 -- set Interface eth2 ofport=10
> 
> Signed-off-by: Isaku Yamahata 

Usually we don't ovs-vswitchd both read and write a single column,
because it can cause confusion.  In this case, for example,
controllers can currently use the ofport column to figure out when a
newly added port has been assigned an OpenFlow port number.  This
commit would make that information harder to interpret (although the
information can still be obtained other ways).

In other cases where there is a need for ovs-vswitchd both to inform
the controller of a value and to take requests for that value, we
generally use two separate columns (or key-value pairs).  For example,
for OpenFlow datapath ID, the datapath_id column in the Bridge table
reports the in-use datapath ID, and the other-config:datapath-id value
requests a particular datapath ID.  I'd suggest using a similar
approach here.

But there's another issue too.  As part of the ongoing effort to
upstream tunneling to the Linux kernel, Justin is currently reworking
how ports are assigned to datapaths.  That work is going to change a
lot of the code in this area, and we've considered adding the ability
to request OpenFlow port numbers as part of it.  So, if requesting
particular port numbers is important to you, I'd suggest coordinating
with Justin.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/4] dpif-netdev: Add SCTP support

2012-10-01 Thread Ben Pfaff 
On Tue, Oct 02, 2012 at 12:44:53AM +1300, Joe Stringer wrote:
> On 28 September 2012 04:53, Ben Pfaff  wrote:
> > "sparse" reports a potential byte-swapping error:
> 
> I would imagine this is because the CRC32C implementation I introduced
> in patch #1 purports to calculate checksums in HBO. Perhaps that
> should be modified to use ovs_be32?

If the CRC32C implementation returns a network-byte-order value, then
yes it should return it as an ovs_be32.

> > It looks to me like the SCTP checksum is getting computed across the
> > entire packet, including the Ethernet header.  I doubt that that can
> > be correct.  Can you take a look?
> 
> I wasn't 100% confident that I understood how the function was
> interacting with the ofpbuf struct, so it's likely I've simply got it
> wrong. With a fresh look it seems like I should actually be using *sh
> to calculate the checksum. I'll make the modification for round two.

"*sh"?

I'd guess that the correct place to start the checksum is the l4
pointer, but I haven't read the SCTP spec.

> Do we currently have code that triggers this? I take it that this type
> of recalculation is required when we modify the packet, eg set-field
> action. What I'd like to know is how I might test that the behaviour
> is correct.

There's no test code right now that modifies the checksum of an SCTP
packet.  I'd suggest using set-field actions of the SCTP source and
dest ports to trigger it.

You could use a tool like Wireshark to verify that the modified packet
was correct.

Once you have manually constructed a test case that you know is
correct, we should add that to the unit tests so that it stays
correct.  There are existing tests that run packets through the
switch; you should be able to follow that model.

> One idea perhaps would be to place OVS between two hosts and make it
> change the destination port on flows in one direction, then using
> lksctp, see whether the hosts continue to communicate correctly. This
> has been my general approach to testing this patchset. The downside is
> that it's a lot of overhead to set up, unlike the autotests.

That's a good thing to try once, as part of constructing an automatic
test case.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 1/2] ovs-ctl: Add support for glibc malloc debugging.

2012-10-01 Thread Ben Pfaff 
Unlike valgrind, glibc's built-in features for malloc debugging are cheap
enough that one can run with them enabled all the time, at least in test
scenarios.

Signed-off-by: Ben Pfaff 
---
 utilities/ovs-ctl.8  |8 +++-
 utilities/ovs-lib.in |3 +++
 2 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/utilities/ovs-ctl.8 b/utilities/ovs-ctl.8
index 22db06b..7bb8fa3 100644
--- a/utilities/ovs-ctl.8
+++ b/utilities/ovs-ctl.8
@@ -198,15 +198,21 @@ Run the daemon under \fBvalgrind\fR(1), if it is 
installed, logging to
 .IP "\fBstrace\fR"
 Run the daemon under \fBstrace\fR(1), if it is installed, logging to
 \fIdaemon\fB.strace.log.\fIpid\fR in the log directory.
+.
+.IP "\fBglibc\fR"
+Enable GNU C library features designed to find memory errors.
 .RE
 .
 .IP
 By default, no wrapper is used.
 .
 .IP
-Wrappers greatly slow daemon operations so they should not be used in
+The \fBvalgring\fR and \fBstrace\fR
+wrappers greatly slow daemon operations so they should not be used in
 production.  They also produce voluminous logs that can quickly fill
 small disk partitions.
+The \fBglibc\fR wrapper is less resource-intensive but still somewhat
+slows the daemons.
 .
 .PP
 The following options control file locations.  They should only be
diff --git a/utilities/ovs-lib.in b/utilities/ovs-lib.in
index 01f4ded..b787b1c 100644
--- a/utilities/ovs-lib.in
+++ b/utilities/ovs-lib.in
@@ -140,6 +140,9 @@ start_daemon () {
 log_failure_msg "strace not installed, running $daemon without 
it"
 fi
 ;;
+glibc)
+set env MALLOC_CHECK_=2 MALLOC_PERTURB_=165 "$@"
+;;
 '')
 ;;
 *)
-- 
1.7.2.5

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 2/2] tests: Enable glibc malloc debugging features in testsuite.

2012-10-01 Thread Ben Pfaff 
I don't know of a reason not to use these features for testing.

Signed-off-by: Ben Pfaff 
---
 tests/atlocal.in |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/tests/atlocal.in b/tests/atlocal.in
index 5360225..8d0f59d 100644
--- a/tests/atlocal.in
+++ b/tests/atlocal.in
@@ -32,3 +32,9 @@ if test $HAVE_PYTHON = yes; then
 export PYTHONPATH
 fi
 fi
+
+# Enable glibc malloc debugging features.
+MALLOC_CHECK_=2
+MALLOC_PERTURB_=165
+export MALLOC_CHECK_
+export MALLOC_PERTURB_
-- 
1.7.2.5

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] tests: Enable glibc malloc debugging features in testsuite.

2012-10-01 Thread Kyle Mestery (kmestery) 
On Oct 1, 2012, at 1:03 PM, Ben Pfaff wrote:
> I don't know of a reason not to use these features for testing.
> 
> Signed-off-by: Ben Pfaff 


Both of these look good to me Ben. As a style nit, any reason
not to combine setting and exporting the variables on the same
line?

Acked-by: Kyle Mestery 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Fedora RPM specfile changes

2012-10-01 Thread Kyle Mestery (kmestery) 
I'm looking at adding support for building RPMs from the upstream OVS for
Fedora systems now. One question I have, and this may apply more to the
Fedora folks who lurk on this list than the OVS folks, is how much does it
matter how close the RPM build of upstream OVS matches the one in the
Fedora project? I have some existing spec files I've been using internally to
build OVS for Fedora for a while now, but they are very different than the
ones upstream for Fedora 18. If it doesn't matter how different things are,
then I may just submit a patch with my existing ones.

Any comments?

Thanks,
Kyle
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] FAQ: Describe how bonded ports interact with OpenFlow.

2012-10-01 Thread Ben Pfaff 
Signed-off-by: Ben Pfaff 
---
 FAQ |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/FAQ b/FAQ
index a98739c..b14bfa4 100644
--- a/FAQ
+++ b/FAQ
@@ -747,6 +747,27 @@ A: ovs-dpctl queries a kernel datapath, not an OpenFlow 
switch.  It
won't display the information that you want.  You want to use
"ovs-ofctl dump-flows" instead.
 
+Q: It looks like each of the interfaces in my bonded port shows up
+   as an individual OpenFlow port.  Is that right?
+
+A: Yes, Open vSwitch makes individual bond interfaces visible as
+   OpenFlow ports, rather than the bond as a whole.  The interfaces
+   are treated together as a bond for only a few purposes:
+
+   - Sending a packet to the OFPP_NORMAL port.  (When an OpenFlow
+ controller is not configured, this happens implicitly to
+ every packet.)
+
+   - The "autopath" Nicira extension action.  However, "autopath"
+ is deprecated and scheduled for removal in February 2013.
+
+   - Mirrors configured for output to a bonded port.
+
+   It would make a lot of sense for Open vSwitch to present a bond as
+   a single OpenFlow port.  If you want to contribute an
+   implementation of such a feature, please bring it up on the Open
+   vSwitch development mailing list at dev@openvswitch.org.
+
 Contact 
 ---
 
-- 
1.7.2.5

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] FAQ: Describe how bonded ports interact with OpenFlow.

2012-10-01 Thread Kyle Mestery (kmestery) 
On Oct 1, 2012, at 3:18 PM, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff 


Nice explanation, this is something interesting to work on, if I have time, I
may take this up.

Acked-by: Kyle Mestery 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] FAQ: Describe how bonded ports interact with OpenFlow.

2012-10-01 Thread Ethan Jackson 
Acked-by: Ethan Jackson 


On Mon, Oct 1, 2012 at 1:18 PM, Ben Pfaff  wrote:
> Signed-off-by: Ben Pfaff 
> ---
>  FAQ |   21 +
>  1 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/FAQ b/FAQ
> index a98739c..b14bfa4 100644
> --- a/FAQ
> +++ b/FAQ
> @@ -747,6 +747,27 @@ A: ovs-dpctl queries a kernel datapath, not an OpenFlow 
> switch.  It
> won't display the information that you want.  You want to use
> "ovs-ofctl dump-flows" instead.
>
> +Q: It looks like each of the interfaces in my bonded port shows up
> +   as an individual OpenFlow port.  Is that right?
> +
> +A: Yes, Open vSwitch makes individual bond interfaces visible as
> +   OpenFlow ports, rather than the bond as a whole.  The interfaces
> +   are treated together as a bond for only a few purposes:
> +
> +   - Sending a packet to the OFPP_NORMAL port.  (When an OpenFlow
> + controller is not configured, this happens implicitly to
> + every packet.)
> +
> +   - The "autopath" Nicira extension action.  However, "autopath"
> + is deprecated and scheduled for removal in February 2013.
> +
> +   - Mirrors configured for output to a bonded port.
> +
> +   It would make a lot of sense for Open vSwitch to present a bond as
> +   a single OpenFlow port.  If you want to contribute an
> +   implementation of such a feature, please bring it up on the Open
> +   vSwitch development mailing list at dev@openvswitch.org.
> +
>  Contact
>  ---
>
> --
> 1.7.2.5
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] FAQ: Describe how bonded ports interact with OpenFlow.

2012-10-01 Thread Ben Pfaff 
On Mon, Oct 01, 2012 at 08:20:15PM +, Kyle Mestery (kmestery) wrote:
> On Oct 1, 2012, at 3:18 PM, Ben Pfaff wrote:
> > Signed-off-by: Ben Pfaff 
> 
> 
> Nice explanation, this is something interesting to work on, if I have time, I
> may take this up.
> 
> Acked-by: Kyle Mestery 

Kyle and Ethan, thanks for the acks.  I applied this to master.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/2] ovs-ctl: Add support for glibc malloc debugging.

2012-10-01 Thread Justin Pettit 
On Oct 1, 2012, at 11:03 AM, Ben Pfaff  wrote:

> +glibc)
> +set env MALLOC_CHECK_=2 MALLOC_PERTURB_=165 "$@"

It may be worth mentioning in the man page that this configuration of 
MALLOC_CHECK_ may cause the system to crash if there are memory problems.

--Justin


___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/2] ovs-ctl: Add support for glibc malloc debugging.

2012-10-01 Thread Ben Pfaff 
On Mon, Oct 01, 2012 at 01:28:40PM -0700, Justin Pettit wrote:
> On Oct 1, 2012, at 11:03 AM, Ben Pfaff  wrote:
> 
> > +glibc)
> > +set env MALLOC_CHECK_=2 MALLOC_PERTURB_=165 "$@"
> 
> It may be worth mentioning in the man page that this configuration
> of MALLOC_CHECK_ may cause the system to crash if there are memory
> problems.

Good point.  I added a sentence to the documentation:

Each of the wrappers can expose bugs in Open vSwitch that lead to
incorrect operation, including crashes.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] tests: Enable glibc malloc debugging features in testsuite.

2012-10-01 Thread Ben Pfaff 
On Mon, Oct 01, 2012 at 06:11:24PM +, Kyle Mestery (kmestery) wrote:
> On Oct 1, 2012, at 1:03 PM, Ben Pfaff wrote:
> > I don't know of a reason not to use these features for testing.
> > 
> > Signed-off-by: Ben Pfaff 
> 
> 
> Both of these look good to me Ben.

Thanks.

> As a style nit, any reason not to combine setting and exporting the
> variables on the same line?

Just that the other assignments in atlocal.in use two lines.  If you
really like the single-line style, I'd take a patch to convert the
whole file.

> Acked-by: Kyle Mestery 

Added and pushed, thank you.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] tests: Also enable FreeBSD libc debugging

2012-10-01 Thread Ed Maste 
Signed-off-by: Ed Maste 
---
There should probably be an OS check to set only the appropriate environment
variables.  I'm not sure if there's a generic autotest way to do that while
building atlocal from atlocal.in though (vs. a switch on $(uname) in the
generated file).  Perhaps not worth addressing, since they're just env vars.

 tests/atlocal.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/atlocal.in b/tests/atlocal.in
index 8d0f59d..c23f8e9 100644
--- a/tests/atlocal.in
+++ b/tests/atlocal.in
@@ -38,3 +38,7 @@ MALLOC_CHECK_=2
 MALLOC_PERTURB_=165
 export MALLOC_CHECK_
 export MALLOC_PERTURB_
+
+# Enable FreeBSD libc malloc debugging features.
+MALLOC_CONF=AJ
+export MALLOC_CONF
-- 
1.7.11.5

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] tests: Also enable FreeBSD libc debugging

2012-10-01 Thread Ben Pfaff 
On Mon, Oct 01, 2012 at 09:11:31PM +, Ed Maste wrote:
> Signed-off-by: Ed Maste 

Applied, thanks.

> There should probably be an OS check to set only the appropriate environment
> variables.  I'm not sure if there's a generic autotest way to do that while
> building atlocal from atlocal.in though (vs. a switch on $(uname) in the
> generated file).  Perhaps not worth addressing, since they're just env vars.

The latter was my own thought.

Do you guys use ovs-ctl (or plan to?).  I'd happily take a patch to
ovs-lib to add freebsd support there.  I guess we'd either rename the
"glibc" wrapper to something more generic or add a "bsd" or "freebsd"
wrapper; I'd be OK with either choice.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] build: Add support for building RPMs for Fedora Linux

2012-10-01 Thread Kyle Mestery 
Add RPM specfiles for building OVS for Fedora Linux. This
allows users of the upstream project the ability to
generate RPMs for their Open vSwitch needs.

Signed-off-by: Kyle Mestery 
---
 INSTALL.Fedora   |  53 +
 rhel/.gitignore  |   2 +
 rhel/automake.mk |  10 ++
 rhel/openvswitch-fedora.spec.in  | 217 +++
 rhel/openvswitch-kmod-fedora.spec.in |  67 +++
 5 files changed, 349 insertions(+)
 create mode 100644 INSTALL.Fedora
 create mode 100644 rhel/openvswitch-fedora.spec.in
 create mode 100644 rhel/openvswitch-kmod-fedora.spec.in

diff --git a/INSTALL.Fedora b/INSTALL.Fedora
new file mode 100644
index 000..e5078dc
--- /dev/null
+++ b/INSTALL.Fedora
@@ -0,0 +1,53 @@
+   How to Install Open vSwitch on Fedora Linux
+   ===
+
+This document describes how to build and install Open vSwitch on a Fedora
+Linux host.  If you want to install Open vSwitch on a generic Linux host,
+see INSTALL.Linux instead.
+
+We have tested these instructions with Fedora 15.
+
+Building Open vSwitch for Fedora
+
+
+You may build from an Open vSwitch distribution tarball or from an
+Open vSwitch Git tree.
+
+Before you begin, note the RPM source directory on your version of
+Fedora.  On Fedora 15, it is $HOME/rpmbuild/SOURCES.
+
+1. If you are building from an Open vSwitch Git tree, then you will
+   need to first create a distribution tarball by running "./boot.sh;
+   ./configure; make dist" in the Git tree.
+
+2. Copy the distribution tarball into the RPM source directory.
+
+3. Unpack the distribution tarball into a temporary directory and "cd"
+   into the root of the distribution tarball.
+
+4. To build Open vSwitch userspace, run:
+
+   rpmbuild -bb rhel/openvswitch-fedora.spec
+
+   This produces one RPM: "openvswitch".
+
+5. On Fedora 15, to build the Open vSwitch kernel module, run:
+
+   rpmbuild -bb rhel/openvswitch-kmod-fedora.spec
+
+You might have to specify a kernel version and/or variants, e.g.:
+
+   rpmbuild -bb \
+   -D "kversion 2.6.32-131.6.1.el6.x86_64" \
+   -D "kflavors default debug kdump" \
+   rhel/openvswitch-kmod-rhel6.spec
+
+This produces an "kmod-openvswitch" RPM for each kernel variant,
+in this example: "kmod-openvswitch", "kmod-openvswitch-debug", and
+"kmod-openvswitch-kdump".
+
+Reporting Bugs
+--
+
+Please report problems to dev@openvswitch.org.
+
diff --git a/rhel/.gitignore b/rhel/.gitignore
index 69e69b9..fa2554f 100644
--- a/rhel/.gitignore
+++ b/rhel/.gitignore
@@ -1,3 +1,5 @@
 openvswitch-kmod-rhel5.spec
 openvswitch-kmod-rhel6.spec
+openvswitch-kmod-fedora.spec
 openvswitch.spec
+openvswitch-fedora.spec
diff --git a/rhel/automake.mk b/rhel/automake.mk
index 4c1d782..eeb4264 100644
--- a/rhel/automake.mk
+++ b/rhel/automake.mk
@@ -17,8 +17,12 @@ EXTRA_DIST += \
rhel/openvswitch-kmod-rhel5.spec.in \
rhel/openvswitch-kmod-rhel6.spec \
rhel/openvswitch-kmod-rhel6.spec.in \
+   rhel/openvswitch-kmod-fedora.spec \
+   rhel/openvswitch-kmod-fedora.spec.in \
rhel/openvswitch.spec \
rhel/openvswitch.spec.in \
+   rhel/openvswitch-fedora.spec \
+   rhel/openvswitch-fedora.spec.in \
rhel/usr_share_openvswitch_scripts_sysconfig.template
 
 update_rhel_spec = \
@@ -32,5 +36,11 @@ $(srcdir)/rhel/openvswitch-kmod-rhel5.spec: 
rhel/openvswitch-kmod-rhel5.spec.in
 $(srcdir)/rhel/openvswitch-kmod-rhel6.spec: 
rhel/openvswitch-kmod-rhel6.spec.in $(top_builddir)/config.status
$(update_rhel_spec)
 
+$(srcdir)/rhel/openvswitch-kmod-fedora.spec: 
rhel/openvswitch-kmod-fedora.spec.in $(top_builddir)/config.status
+   $(update_rhel_spec)
+
 $(srcdir)/rhel/openvswitch.spec: rhel/openvswitch.spec.in 
$(top_builddir)/config.status
$(update_rhel_spec)
+
+$(srcdir)/rhel/openvswitch-fedora.spec: rhel/openvswitch-fedora.spec.in 
$(top_builddir)/config.status
+   $(update_rhel_spec)
diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
new file mode 100644
index 000..4fcbf0e
--- /dev/null
+++ b/rhel/openvswitch-fedora.spec.in
@@ -0,0 +1,217 @@
+# Spec file for Open vSwitch.
+
+# Copyright (C) 2009, 2010 Nicira Networks, Inc.
+#
+# Copying and distribution of this file, with or without modification,
+# are permitted in any medium without royalty provided the copyright
+# notice and this notice are preserved.  This file is offered as-is,
+# without warranty of any kind.
+
+#%define kernel 2.6.40.4-5.fc15.x86_64
+
+Name: openvswitch
+Summary: Open vSwitch
+Group: System Environment/Daemons
+URL: http://www.openvswitch.org/
+Vendor: OpenSource Security Ralf Spenneberg 
+Version: @VERSION@
+
+# The entire source code is ASL 2.0 except datapath/ which is GPLv2
+License: ASL 2.0
+Release: 1%{?dist}
+Source: openvswitch-%{version}.t

Re: [ovs-dev] [PATCH] tests: Also enable FreeBSD libc debugging

2012-10-01 Thread Ed Maste 
On 1 October 2012 17:19, Ben Pfaff  wrote:
> On Mon, Oct 01, 2012 at 09:11:31PM +, Ed Maste wrote:
>> Signed-off-by: Ed Maste 
>
> Applied, thanks.
>
>> There should probably be an OS check to set only the appropriate environment
>> variables.  I'm not sure if there's a generic autotest way to do that while
>> building atlocal from atlocal.in though (vs. a switch on $(uname) in the
>> generated file).  Perhaps not worth addressing, since they're just env vars.
>
> The latter was my own thought.

Ahh, as it turns out the new jemalloc in FreeBSD 10 uses a different
config string format, so I'll eventually need a uname switch anyway
(although the FreeBSD 10 release is a ways off).

Does something like this seem reasonable?

diff --git a/tests/atlocal.in b/tests/atlocal.in
index c23f8e9..5604bf0 100644
--- a/tests/atlocal.in
+++ b/tests/atlocal.in
@@ -33,12 +33,23 @@ if test $HAVE_PYTHON = yes; then
 fi
 fi

-# Enable glibc malloc debugging features.
-MALLOC_CHECK_=2
-MALLOC_PERTURB_=165
-export MALLOC_CHECK_
-export MALLOC_PERTURB_
-
-# Enable FreeBSD libc malloc debugging features.
-MALLOC_CONF=AJ
-export MALLOC_CONF
+case $(uname) in
+Linux)
+# Enable glibc malloc debugging features.
+MALLOC_CHECK_=2
+MALLOC_PERTURB_=165
+export MALLOC_CHECK_
+export MALLOC_PERTURB_
+;;
+FreeBSD)
+# Enable FreeBSD libc malloc debugging features.
+case $(uname -r) in
+8*|9*)
+MALLOC_CONF=AJ
+;;
+10*)
+MALLOC_CONF=abort:true,junk:true,redzone:true
+;;
+esac
+export MALLOC_CONF
+esac


> Do you guys use ovs-ctl (or plan to?).  I'd happily take a patch to
> ovs-lib to add freebsd support there.  I guess we'd either rename the
> "glibc" wrapper to something more generic or add a "bsd" or "freebsd"
> wrapper; I'd be OK with either choice.

We're not currently using ovs-ctl.  Probably the closet right now is
start scripts in the FreeBSD ports tree for the db and vswitchd:

http://svnweb.freebsd.org/ports/head/net/openvswitch/files/ovsdb-server.in?revision=302330&view=markup
http://svnweb.freebsd.org/ports/head/net/openvswitch/files/ovs-vswitchd.in?view=markup

On a quick look there are some interesting bits in ovs-ctl and ovs-lib
- I'll try to investigate in more detail.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] tests: Also enable FreeBSD libc debugging

2012-10-01 Thread Ben Pfaff 
On Mon, Oct 01, 2012 at 05:40:29PM -0400, Ed Maste wrote:
> On 1 October 2012 17:19, Ben Pfaff  wrote:
> > On Mon, Oct 01, 2012 at 09:11:31PM +, Ed Maste wrote:
> >> Signed-off-by: Ed Maste 
> >
> > Applied, thanks.
> >
> >> There should probably be an OS check to set only the appropriate 
> >> environment
> >> variables.  I'm not sure if there's a generic autotest way to do that while
> >> building atlocal from atlocal.in though (vs. a switch on $(uname) in the
> >> generated file).  Perhaps not worth addressing, since they're just env 
> >> vars.
> >
> > The latter was my own thought.
> 
> Ahh, as it turns out the new jemalloc in FreeBSD 10 uses a different
> config string format, so I'll eventually need a uname switch anyway
> (although the FreeBSD 10 release is a ways off).
> 
> Does something like this seem reasonable?

Sure.  I'd use `` instead of $() because the Autoconf manual says that
it is more portable use of shell, but everything else looks good to me.

> > Do you guys use ovs-ctl (or plan to?).  I'd happily take a patch to
> > ovs-lib to add freebsd support there.  I guess we'd either rename the
> > "glibc" wrapper to something more generic or add a "bsd" or "freebsd"
> > wrapper; I'd be OK with either choice.
> 
> We're not currently using ovs-ctl.  Probably the closet right now is
> start scripts in the FreeBSD ports tree for the db and vswitchd:
> 
> http://svnweb.freebsd.org/ports/head/net/openvswitch/files/ovsdb-server.in?revision=302330&view=markup
> http://svnweb.freebsd.org/ports/head/net/openvswitch/files/ovs-vswitchd.in?view=markup
> 
> On a quick look there are some interesting bits in ovs-ctl and ovs-lib
> - I'll try to investigate in more detail.

Your scripts are certainly an order of magnitude simpler, there's a
lot to like in that ;-)
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Máquina de afeitar corporal / Redutor de papada / Evádete del estres en el Albaicín de Granada

2012-10-01 Thread GlobalBono 
Cabestan. Layout Simple
   Asegúrate de no perderte ninguna oferta, añade ofer...@globalbono.com a tu 
lista de contactos.
Si no ves correctamente las imágenes, pulsa [ 
http://email.globalbono.com/E01102012143248.cfm?WL=1671&WS=208833_8707685&WA=859
 ] aquí
[ http://email.globalbono.com/Go/index.cfm?WL=564&WS=208833_8707685&WA=859 ]
 Tus Ofertas de hoy
Síguenos en:
[ http://email.globalbono.com/Go/index.cfm?WL=50&WS=208833_8707685&WA=859 ] [ 
http://email.globalbono.com/Go/index.cfm?WL=51&WS=208833_8707685&WA=859 ] 







[ http://email.globalbono.com/Go/index.cfm?WL=1152&WS=208833_8707685&WA=859 ] 



[ http://email.globalbono.com/Go/index.cfm?WL=1651&WS=208833_8707685&WA=859 ] 
56% Dto. Plantillas Ergonómicas. Y di adiós al dolor de pies.
Tú como muchos otros, piensas que es normal que te duelan los pies. Tienes un 
trabajo que te obliga a p...

15,44¤


[ http://email.globalbono.com/Go/index.cfm?WL=1651&WS=208833_8707685&WA=859 ] 


Antes

35,25¤Dto: 56%
Ahorro: 19,81¤
















[ http://email.globalbono.com/Go/index.cfm?WL=1650&WS=208833_8707685&WA=859 ] 
52% Dto. Máquina de afeitar corporal masculina
El bello corporal es un problema estético cada vez para más hombres. Si eres 
uno de esas personas a las...

12,38¤


[ http://email.globalbono.com/Go/index.cfm?WL=1650&WS=208833_8707685&WA=859 ] 


Antes

25,96¤Dto: 52%
Ahorro: 13,58¤
















[ http://email.globalbono.com/Go/index.cfm?WL=1652&WS=208833_8707685&WA=859 ] 
56% Dto. Reductor de Papada. Estiliza tu perfil.
Un día te levantas y te miras al espejo. Como por arte de magia a aparecido una 
incipiente papada que h...

9,06¤


[ http://email.globalbono.com/Go/index.cfm?WL=1652&WS=208833_8707685&WA=859 ] 


Antes

20,36¤Dto: 56%
Ahorro: 11,30¤
















[ http://email.globalbono.com/Go/index.cfm?WL=1654&WS=208833_8707685&WA=859 ] 
58% Dto. Evádete del estres por el Albaicín de Granada con Tapeo guiado. 
Si hay una ciudad con encanto y duende sin duda esa es Granada. De las ocho 
provincias que componen And...

40,00¤


[ http://email.globalbono.com/Go/index.cfm?WL=1654&WS=208833_8707685&WA=859 ] 


Antes

95,00¤Dto: 58%
Ahorro: 55,00¤
















[ http://email.globalbono.com/Go/index.cfm?WL=1653&WS=208833_8707685&WA=859 ] 
67% Dto. Escápate!! Pesca y cocina tu trucha y descubre TERUEL.
Descubre Teruel de una forma diferente. La escapada que te proponemos cumple el 
refrán yo me lo ...

40,00¤


[ http://email.globalbono.com/Go/index.cfm?WL=1653&WS=208833_8707685&WA=859 ] 


Antes

120,00¤Dto: 67%
Ahorro: 80,00¤
















[ http://email.globalbono.com/Go/index.cfm?WL=1583&WS=208833_8707685&WA=859 ] 
56% Dto. Escapada RELAX en Ávila. Descansa el cuerpo y la mente.
Disfruta de una completa sesión de relajación con esta estupenda escapada que 
te ofrecemos. Podrás disf...

140,00¤


[ http://email.globalbono.com/Go/index.cfm?WL=1583&WS=208833_8707685&WA=859 ] 


Antes

320,00¤Dto: 56%
Ahorro: 180,00¤















[ http://email.globalbono.com/Go/index.cfm?WL=706&WS=208833_8707685&WA=859 ] 



De conformidad con lo que establece la Ley Orgánica 15/1999 de Protección de 
Datos de Carácter Personal, le informamos que sus datos personales serán 
incorporados a un fichero bajo la responsabilidad de GlobalBono, con la 
finalidad de poder atender los compromisos derivados de la relación que 
mantenemos con usted. Puede ejercer sus derechos de acceso, cancelación, 
rectificación y oposición mediante un escrito a la dirección email 
i...@globalbono.com. Si en el plazo de 30 días no nos comunica lo contrario, 
entenderemos que los datos no han sido modificados, que se compromete a 
notificarnos cualquier variación y que tenemos el consentimiento para 
utilizarlos a fin de poder fidelizar la relación entre las partes.
   ¿Quieres dejar de recibir este email? Haz click  [ 
http://email.globalbono.com/baja/form_baja_GB.cfm?WL=182&WS=208833_8707685&WA=859
 ] aquí. 


___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Willing to help?

2012-10-01 Thread Ben Kossi 


My dear One,
My name is Mr. Ben Kossi, the Secretary to the former Government Mr.Laurent 
Gbagbo president of Cote d Ivory in West Africa, I have funds 800,000.00 US 
dollars, in my possession which the president handed over tome to pay inn 
before the political crises. I want to move this fund(s) that where about to be 
moved into federal government account because there is no ownership to the 
fund(s). All I need from you is your interest to be my foreign partner so that 
things will be done with cordial relationship, equity and rationality.
 
I have a plan to load the fund in ATM MASTER CARDS and send them to you through 
bank so that the fund will be withdrawn from the card on daily basis until we 
have the last cent, otherwise using any other method will involve a lot of 
processes that will eventually not come to an end like getting several 
certificates, payments of insurance fee(s), then using diplomats and lots more. 
If you assure me of your partnership I will show you the simple way this can be 
done and in less than five days we will celebrate.
 
Thanks,
Sincerely
Mr.Ben Kossi___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Threaded userspace datapath

2012-10-01 Thread Jesse Gross 
On Sat, Sep 29, 2012 at 7:05 AM, Luigi Rizzo  wrote:
> jumping in the conversation: last year when Gaetano and I worked on
> this code, the main loop had multiple performance issues, including
> a) rebuilding from scratch the list of file descriptors on each iteration,
> b) ignoring the response from select() and firing all handlers (and perhaps
>looking at timeouts ?) on return, and
> c) processing only one packet per iteration.
>
> Our feeling at the time was that:
> - a patch that fixed #a and #b in the main loop would have a much lower
>   chance of being accepted;
> - user-space forwarding was not a priority fo the project given the existence 
> of
>   the in-kernel module for linux (though we may disagree on this, given that
>   together with netmap this makes it possible to get much better throughput);
> - we were unsure how much #a could be simplified in the main loop, whereas
>   splitting the event loop in two makes the handling of the forwarding path a
>   lot more efficient;
> - also having a separate forwarding thread probably would save some latency
>   in the forwarding when the main thread is busy with the control path.
>
>  and these are the reasons why we went for a separate thread.
> Also, we were not completely sure on how to address
> #a in the main loop, whereas this is somewhat simpler in the secondary
> thread which only has to deal with the dp_netdevs list.
>
> An option to move forward could be to make the entire patch conditional
> (it almost is this way now, but we can certainly work on making the patch
> less intrusive and clearly mark the conditional block) and possibly default
> to off, so that people not comfortable with the threaded extension
> will not have to deal with it.
>
> In the meantime you can perhaps try to
> import some of the performance enhancements in the main code
> (though again i am not sure how efficiently high-speed packet-IO events
> can coexist with the control-plane related one.

I can definitely see an argument for keeping control traffic and
packet processing separate, both from a strict efficiency perspetive
and also just in terms of separation of concerns.  If there are
benefits to be gained by making changes to the main loop then it would
be nice to get those everywhere but that obviously shouldn't block
other work.

I would actually prefer to see less rather than more conditional code,
especially with synchronization.  If it's conditional, in the best
case you always have to worry about the most complicated case and in
the worst case you either have to worry about multiple case or
accidentally break things.  These types of situations make me
particularly nervous when they start leaking out into other parts of
the code, as we see with the vlog library.

Given that the source of the gains are structural, rather than due to
fine grained threading, the most natural approach to me would to be a
multiprocess model.  This would seem to have all of the benefits with
none of the worries about synchronization.  It also has the benefits
of very closely modeling the kernel datapath.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Threaded userspace datapath

2012-10-01 Thread Jesse Gross 
On Sat, Sep 29, 2012 at 12:17 AM, Giuseppe Lettieri
 wrote:
>
> Il giorno 29/set/2012, alle ore 01:44, Jesse Gross  ha 
> scritto:
>
>> Does this actually require changing the main loop?  If it really is
>> the poll related changes that you mention it seems like they could be
>> contained to the netdevs and userspace datapath.  You could handle a
>> batch of packets each time through the main loop.
>
>
> Well, I see what you mean. Indeed, it was me that raised the issue on the 
> list. But the poll related changes I mentioned where just an hypothesis. Take 
> the batching issue you are referring to, for example: if I disable batching 
> in the threaded datapath (just put batch=1), performance drops by  ~20% only. 
> From this I get that the big problem with the existing loop lies elsewhere. I 
> am not saying that it really needs drastic changes, only that it might, and 
> we had no time to investigate. This is only in reply to your question of why 
> we continued down this road.
>
> I understand that our lack of time is no good reason to accept a patch. On 
> the other end, I tried to push it anyway since it solves a real problem for 
> FreeBSD people, maybe also PlanetLab users, and possibly others.

Thanks, I definitely understand trying to get something in now even if
there are potentially more optimizations that can be made in the
future.  As I mentioned in the other message, processes seem a lot
simpler to me as an immediate solution (with hopefully known
performance characteristics) and maybe we can get some of the other
optimizations to the main loop in the future.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] build: Add support for building RPMs for Fedora Linux

2012-10-01 Thread Ben Pfaff 
On Mon, Oct 01, 2012 at 05:20:32PM -0400, Kyle Mestery wrote:
> Add RPM specfiles for building OVS for Fedora Linux. This
> allows users of the upstream project the ability to
> generate RPMs for their Open vSwitch needs.
> 
> Signed-off-by: Kyle Mestery 

Thanks.  I have only a few comments.

The s below extend past the title:

> +   How to Install Open vSwitch on Fedora Linux
> +   ===
> +
> +This document describes how to build and install Open vSwitch on a Fedora
> +Linux host.  If you want to install Open vSwitch on a generic Linux host,
> +see INSTALL.Linux instead.

The instructions are very clear.  Thanks for that.

> +We have tested these instructions with Fedora 15.

I think we normally recommend b...@openvswitch.org for bug reports:

> +Reporting Bugs
> +--
> +
> +Please report problems to dev@openvswitch.org.

INSTALL.Fedora has an extra blank line at the end.

The spec files mention "OpenSource Security Ralf Spenneberg
" as vendor and in the changelog.  Where does that come
from?  (Do we need to get Ralf Spenneberg's Signed-off-by?)

I think that we can drop the %post fragment that mentions xhad.  That's
a proprietary high-availability daemon that, as far as I know, only
XenServer uses.  (Do our RHEL spec files include this?  They can
probably omit it too, then.)

It looks like the RPM omits ovs-bugtool and much of the infrastructure
that it uses.  It would be nice to include it, because ovs-bugtool
occasionally makes bugs much easier to find.

Thanks,

Ben.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] vswitch: allow to specify ofport when creating port

2012-10-01 Thread Justin Pettit 
On Oct 1, 2012, at 10:08 AM, Ben Pfaff  wrote:

> But there's another issue too.  As part of the ongoing effort to
> upstream tunneling to the Linux kernel, Justin is currently reworking
> how ports are assigned to datapaths.  That work is going to change a
> lot of the code in this area, and we've considered adding the ability
> to request OpenFlow port numbers as part of it.  So, if requesting
> particular port numbers is important to you, I'd suggest coordinating
> with Justin.

Hi, Isaku.  Due to the changes Ben mentioned, I need to be able to assign 
OpenFlow port numbers to make the ofproto-dpif unit tests pass.  I've gotten 
most of the way through a patch to add that support with this new 
infrastructure.  I haven't yet written unit tests, so if you're okay with it, 
I'd like to fold your unit tests (with attribution in the commit log) into my 
patch.  Would you be okay with that?

--Justin


___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] vswitch: allow to specify ofport when creating port

2012-10-01 Thread Isaku Yamahata 
On Mon, Oct 01, 2012 at 11:42:36PM -0700, Justin Pettit wrote:
> On Oct 1, 2012, at 10:08 AM, Ben Pfaff  wrote:
> 
> > But there's another issue too.  As part of the ongoing effort to
> > upstream tunneling to the Linux kernel, Justin is currently reworking
> > how ports are assigned to datapaths.  That work is going to change a
> > lot of the code in this area, and we've considered adding the ability
> > to request OpenFlow port numbers as part of it.  So, if requesting
> > particular port numbers is important to you, I'd suggest coordinating
> > with Justin.
> 
> Hi, Isaku.

Hi.

>  Due to the changes Ben mentioned, I need to be able to assign OpenFlow port 
> numbers to make the ofproto-dpif unit tests pass.  I've gotten most of the 
> way through a patch to add that support with this new infrastructure.  I 
> haven't yet written unit tests, so if you're okay with it, I'd like to fold 
> your unit tests (with attribution in the commit log) into my patch.  Would 
> you be okay with that?

Off course yes.
-- 
yamahata
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev