[ovs-dev] Returned mail: Data format error

[karl]

The message could not be delivered

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

[ovs-dev] [PATCH v11 5/5] userspace: add non-tap (l3) support to GRE vports

[Simon Horman]

Add support for layer 3 GRE vports (non-tap aka non-VTEP).

This makes use of a vport mode configuration for the existing (tap/VTEP)
GRE vports.

In order to differentiate packets for two different types of GRE vports a
new flow key attribute, OVS_KEY_ATTR_NEXT_BASE_LAYER, is used.  It is
intended that this attribute is only used in userspace as there appears to
be no need for it to be used in the kernel datapath.

It is envisaged that this attribute may be used for other encapsulation
protocols that support both layer3 and layer2 inner-packets.

Signed-off-by: Simon Horman 

---
v11
* Update for new kernel implementation that uses ARPHRD_NONE devices
* Omit match_base_layer from struct tun_port_in, it is not necessary any more
* Correct OVS_KEY_ATTR_NEXT_BASE_LAYER handling in odp_flow_key_from_flow__()
  and parse_l2_5_onward() so that the encoding and decoding of the
  next_base_layer field of a flow key is consistent both with itself on
  encode and decode and with other fields of the flow key.
* Guard OVS_KEY_ATTR_TUNNEL_INFO with #ifndef __KERNEL__ in
  openvswitch.h and note that it is only used by the user-space datapath
* Consistently use tabs for indentation
* Correct spelling and capitalisation of documentation
* Append "(layer3)" to when showing layer3 tunnel ports as
  they may share the same ODP port as a non-layer3 tunnel port.
  This seems simpler than v10 which included an O(n**2) filter on
  showing duplicate ports.

v10
* Use a mode for layer3 ports rather than a new port type
* Update BUILD_BUG_ON() call in ovs_key_attr_size()
* Don't update tnl_port_map_lookup() to always match
  on next_base_layer: the implementation didn't actually
  do that and thus was a lot of code change for no behavioural
  change.

v9
* New patch

fix

Signed-off-by: Simon Horman 
---
 datapath/linux/compat/include/linux/openvswitch.h |  3 ++
 include/openvswitch/flow.h|  8 +++-
 lib/flow.c| 34 +++
 lib/match.c   |  6 ++-
 lib/netdev-linux.c|  3 +-
 lib/netdev-native-tnl.c   | 26 +---
 lib/netdev-vport.c| 22 --
 lib/netdev.h  |  1 +
 lib/nx-match.c|  2 +-
 lib/odp-execute.c |  2 +
 lib/odp-util.c| 22 ++
 lib/odp-util.h|  4 +-
 lib/ofp-util.c|  2 +-
 lib/tnl-ports.c   | 51 ---
 lib/tnl-ports.h   |  3 +-
 ofproto/ofproto-dpif-rid.h|  2 +-
 ofproto/ofproto-dpif-sflow.c  |  1 +
 ofproto/ofproto-dpif-xlate.c  |  2 +-
 ofproto/ofproto-dpif.c|  2 +
 ofproto/tunnel.c  |  4 +-
 tests/tunnel-push-pop-ipv6.at | 12 --
 tests/tunnel-push-pop.at  | 26 ++--
 vswitchd/vswitch.xml  | 13 ++
 23 files changed, 201 insertions(+), 50 deletions(-)

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index b0c7988ae9b9..edfa7a1bcdd1 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -358,6 +358,9 @@ enum ovs_key_attr {
 #ifdef __KERNEL__
/* Only used within kernel data path. */
OVS_KEY_ATTR_TUNNEL_INFO,  /* struct ovs_tunnel_info */
+#else
+   /* Only used within user-space data path. */
+   OVS_KEY_ATTR_NEXT_BASE_LAYER, /* base layer of encapsulated packet */
 #endif
__OVS_KEY_ATTR_MAX
 };
diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
index 4e8e31b62578..22b497ec660a 100644
--- a/include/openvswitch/flow.h
+++ b/include/openvswitch/flow.h
@@ -23,7 +23,7 @@
 /* This sequence number should be incremented whenever anything involving flows
  * or the wildcarding of flows changes.  This will cause build assertion
  * failures in places which likely need to be updated. */
-#define FLOW_WC_SEQ 36
+#define FLOW_WC_SEQ 37
 
 /* Number of Open vSwitch extension 32-bit registers. */
 #define FLOW_N_REGS 8
@@ -132,6 +132,10 @@ struct flow {
 ovs_be16 tp_dst;/* TCP/UDP/SCTP destination port/ICMP code. */
 ovs_be32 igmp_group_ip4;/* IGMP group IPv4 address.
  * Keep last for BUILD_ASSERT_DECL below. */
+
+uint8_t next_base_layer;/* Fields of encapsulated packet, if any,
+ * start at this layer */
+uint8_t pad4[7];
 };
 BUILD_ASSERT_DECL(sizeof(struct flow) % sizeof(uint64_t) == 0);
 BUILD_ASSERT_DECL(sizeof(struct flow_tnl) % sizeof(uint64_t) =

[ovs-dev] [PATCH net-next v10 5/5] openvswitch: use ipgre tunnel rather than gretap tunnel

[Simon Horman]

This allows GRE tunnels to send and receive both
layer 2 packets (packets with an ethernet header) and
layer 3 packets (packets without an ethernet header).

Signed-off-by: Simon Horman 
---
v10
* Handle case of l3 only packets on vport-netdev
* Use ARPHRD_NONE for ipgre interfaces as per recent changes in mainline
* Ensure skb->mac_len is set correctly in netdev_port_receive and
  relay on this value to differentiate layer3 packets in
  ovs_flow_key_extract()

Signed-off-by: Simon Horman 
---
 include/net/gre.h  |  4 ++--
 net/ipv4/ip_gre.c  |  9 +
 net/openvswitch/vport-gre.c|  2 +-
 net/openvswitch/vport-netdev.c | 34 --
 4 files changed, 36 insertions(+), 13 deletions(-)

diff --git a/include/net/gre.h b/include/net/gre.h
index 5dce30a6abe3..aeb748a97e0d 100644
--- a/include/net/gre.h
+++ b/include/net/gre.h
@@ -23,8 +23,8 @@ struct gre_protocol {
 int gre_add_protocol(const struct gre_protocol *proto, u8 version);
 int gre_del_protocol(const struct gre_protocol *proto, u8 version);
 
-struct net_device *gretap_fb_dev_create(struct net *net, const char *name,
-  u8 name_assign_type);
+struct net_device *gre_fb_dev_create(struct net *net, const char *name,
+u8 name_assign_type);
 int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
 bool *csum_err, __be16 proto);
 
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 4d2025f7ec57..58d323289872 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1116,8 +1116,8 @@ static struct rtnl_link_ops ipgre_tap_ops __read_mostly = 
{
.get_link_net   = ip_tunnel_get_link_net,
 };
 
-struct net_device *gretap_fb_dev_create(struct net *net, const char *name,
-   u8 name_assign_type)
+struct net_device *gre_fb_dev_create(struct net *net, const char *name,
+u8 name_assign_type)
 {
struct nlattr *tb[IFLA_MAX + 1];
struct net_device *dev;
@@ -1127,13 +1127,14 @@ struct net_device *gretap_fb_dev_create(struct net 
*net, const char *name,
memset(&tb, 0, sizeof(tb));
 
dev = rtnl_create_link(net, name, name_assign_type,
-  &ipgre_tap_ops, tb);
+  &ipgre_link_ops, tb);
if (IS_ERR(dev))
return dev;
 
/* Configure flow based GRE device. */
t = netdev_priv(dev);
t->collect_md = true;
+   dev->type = ARPHRD_NONE;
 
err = ipgre_newlink(net, dev, tb, NULL);
if (err < 0)
@@ -1151,7 +1152,7 @@ out:
free_netdev(dev);
return ERR_PTR(err);
 }
-EXPORT_SYMBOL_GPL(gretap_fb_dev_create);
+EXPORT_SYMBOL_GPL(gre_fb_dev_create);
 
 static int __net_init ipgre_tap_init_net(struct net *net)
 {
diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
index bcbc91b8b077..c1cab9dd392f 100644
--- a/net/openvswitch/vport-gre.c
+++ b/net/openvswitch/vport-gre.c
@@ -60,7 +60,7 @@ static struct vport *gre_tnl_create(const struct vport_parms 
*parms)
return vport;
 
rtnl_lock();
-   dev = gretap_fb_dev_create(net, parms->name, NET_NAME_USER);
+   dev = gre_fb_dev_create(net, parms->name, NET_NAME_USER);
if (IS_ERR(dev)) {
rtnl_unlock();
ovs_vport_free(vport);
diff --git a/net/openvswitch/vport-netdev.c b/net/openvswitch/vport-netdev.c
index 733e7914f6bd..3df36df62ee9 100644
--- a/net/openvswitch/vport-netdev.c
+++ b/net/openvswitch/vport-netdev.c
@@ -60,7 +60,24 @@ static void netdev_port_receive(struct sk_buff *skb)
if (vport->dev->type == ARPHRD_ETHER) {
skb_push(skb, ETH_HLEN);
skb_postpush_rcsum(skb, skb->data, ETH_HLEN);
+   } else if (vport->dev->type == ARPHRD_NONE) {
+   if (skb->protocol == htons(ETH_P_TEB)) {
+   __be16 eth_type;
+
+   if (unlikely(skb->len < ETH_HLEN))
+   goto error;
+
+   eth_type = eth_type_trans(skb, skb->dev);
+   skb->mac_len = skb->data - skb_mac_header(skb);
+   __skb_push(skb, skb->mac_len);
+
+   if (eth_type == htons(ETH_P_8021Q))
+   skb->mac_len += VLAN_HLEN;
+   } else {
+   skb->mac_len = 0;
+   }
}
+
ovs_vport_receive(vport, skb, skb_tunnel_info(skb));
return;
 error:
@@ -99,7 +116,8 @@ struct vport *ovs_netdev_link(struct vport *vport, const 
char *name)
}
 
if (vport->dev->flags & IFF_LOOPBACK ||
-   vport->dev->type != ARPHRD_ETHER ||
+   (vport->dev->type != ARPHRD_ETHER &&
+vport->dev->type != ARPHRD_NONE) ||
ovs_is_internal_dev(vport->dev)) {
err = -EINVAL;
got

[ovs-dev] [PATCH net-next v10 3/5] openvswitch: add support to push and pop mpls for layer3 packets

[Simon Horman]

Allow push and pop mpls actions to act on layer 3 packets by teaching
them not to access non-existent L2 headers of such packets.

Signed-off-by: Simon Horman 
---
v10
* Limit scope of hdr in {push,pop}_mpls()

v9
* New Patch
---
 net/openvswitch/actions.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 9a3eb7a0ebf4..15f130e4c22b 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -172,7 +172,8 @@ static int push_mpls(struct sk_buff *skb, struct 
sw_flow_key *key,
 
skb_postpush_rcsum(skb, new_mpls_lse, MPLS_HLEN);
 
-   update_ethertype(skb, eth_hdr(skb), mpls->mpls_ethertype);
+   if (skb->mac_len)
+   update_ethertype(skb, eth_hdr(skb), mpls->mpls_ethertype);
if (!skb->inner_protocol)
skb_set_inner_protocol(skb, skb->protocol);
skb->protocol = mpls->mpls_ethertype;
@@ -184,7 +185,6 @@ static int push_mpls(struct sk_buff *skb, struct 
sw_flow_key *key,
 static int pop_mpls(struct sk_buff *skb, struct sw_flow_key *key,
const __be16 ethertype)
 {
-   struct ethhdr *hdr;
int err;
 
err = skb_ensure_writable(skb, skb->mac_len + MPLS_HLEN);
@@ -199,11 +199,16 @@ static int pop_mpls(struct sk_buff *skb, struct 
sw_flow_key *key,
__skb_pull(skb, MPLS_HLEN);
skb_reset_mac_header(skb);
 
-   /* skb_mpls_header() is used to locate the ethertype
-* field correctly in the presence of VLAN tags.
-*/
-   hdr = (struct ethhdr *)(skb_mpls_header(skb) - ETH_HLEN);
-   update_ethertype(skb, hdr, ethertype);
+   if (skb->mac_len) {
+   struct ethhdr *hdr;
+
+   /* skb_mpls_header() is used to locate the ethertype
+* field correctly in the presence of VLAN tags.
+*/
+   hdr = (struct ethhdr *)(skb_mpls_header(skb) - ETH_HLEN);
+   update_ethertype(skb, hdr, ethertype);
+   }
+
if (eth_p_mpls(skb->protocol))
skb->protocol = ethertype;
 
-- 
2.1.4

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

[ovs-dev] [PATCH v11 4/5] userspace: extend layer 3 support to cover non-IP packets

[Simon Horman]

Extend support for layer 3 packets to cover non-IP packets.

This removes the assumption that the first octet of a layer 3 packet
indicates the IP protocol version - true for IP (v4 and v6), but not
for necessarily for other protocols.

The key motivation for this is to allow forwarding of MPLS packets which
are technically layer 2.5 rather than 3 but the distinction seems unimportant
here.

This relies on datapaths setting OVS_KEY_ATTR_PACKET_ETHERTYPE to
the ethernet type corresponding to the protocol of layer 3 packets
on a flow miss.

Signed-off-by: Simon Horman 
Acked-by: Ben Pfaff 

---
v11
* Added Ack from Ben Pfaff

v10
* Delete now bogus comment about protocol assumptions for L3 packets

v9
* New patch
---
 include/openvswitch/ofp-print.h |  7 +-
 lib/dp-packet.h |  2 +-
 lib/dpif-netdev.c   |  5 +---
 lib/dpif.c  |  9 ++-
 lib/flow.c  | 40 +--
 lib/odp-util.c  | 53 ++---
 lib/ofp-print.c | 24 +++
 lib/packets.c   | 14 ---
 8 files changed, 90 insertions(+), 64 deletions(-)

diff --git a/include/openvswitch/ofp-print.h b/include/openvswitch/ofp-print.h
index 3e951173acc2..dce80a7cbc88 100644
--- a/include/openvswitch/ofp-print.h
+++ b/include/openvswitch/ofp-print.h
@@ -23,6 +23,8 @@
 #include 
 #include 
 
+#include 
+
 struct ds;
 struct ofp10_match;
 struct ofp_flow_mod;
@@ -30,6 +32,7 @@ struct ofp_header;
 struct ofputil_flow_stats;
 struct ofputil_table_features;
 struct ofputil_table_stats;
+struct dp_packet;
 
 #ifdef  __cplusplus
 extern "C" {
@@ -42,7 +45,9 @@ void ofp10_match_print(struct ds *, const struct ofp10_match 
*, int verbosity);
 
 char *ofp_to_string(const void *, size_t, int verbosity);
 char *ofp10_match_to_string(const struct ofp10_match *, int verbosity);
-char *ofp_packet_to_string(const void *data, size_t len, bool is_layer3);
+char *ofp_packet_to_string(const void *data, size_t len,
+  ovs_be16 packet_ethertype);
+char *ofp_dp_packet_to_string(const struct dp_packet *);
 
 void ofp_print_flow_stats(struct ds *, struct ofputil_flow_stats *);
 void ofp_print_version(const struct ofp_header *, struct ds *);
diff --git a/lib/dp-packet.h b/lib/dp-packet.h
index 6b3ecd974e48..ca788640597f 100644
--- a/lib/dp-packet.h
+++ b/lib/dp-packet.h
@@ -258,7 +258,7 @@ dp_packet_equal(const struct dp_packet *a, const struct 
dp_packet *b)
 static inline bool
 dp_packet_is_l3(const struct dp_packet *b)
 {
-return b->l3_ofs == 0;
+return b->l3_ofs == 0 || b->l2_5_ofs == 0;
 }
 
 /* Get the start of the Ethernet frame.  Return NULL if 'b' is an l3 packet
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 6d79febfc8ed..4cf10dc28876 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3501,10 +3501,7 @@ dp_netdev_upcall(struct dp_netdev_pmd_thread *pmd, 
struct dp_packet *packet_,
 
 ofpbuf_init(&key, 0);
 odp_flow_key_from_flow(&odp_parms, &key);
-packet_str = ofp_packet_to_string(dp_packet_data(packet_),
-  dp_packet_size(packet_),
-  dp_packet_is_l3(packet_));
-
+packet_str = ofp_dp_packet_to_string(packet_);
 odp_flow_key_format(key.data, key.size, &ds);
 
 VLOG_DBG("%s: %s upcall:\n%s\n%s", dp->name,
diff --git a/lib/dpif.c b/lib/dpif.c
index cb9519e2de5c..808109bd4140 100644
--- a/lib/dpif.c
+++ b/lib/dpif.c
@@ -1390,10 +1390,7 @@ dpif_print_packet(struct dpif *dpif, struct dpif_upcall 
*upcall)
 struct ds flow;
 char *packet;
 
-packet = ofp_packet_to_string(dp_packet_data(&upcall->packet),
-  dp_packet_size(&upcall->packet),
-  dp_packet_is_l3(&upcall->packet));
-
+packet = ofp_dp_packet_to_string(&upcall->packet);
 ds_init(&flow);
 odp_flow_key_format(upcall->key, upcall->key_len, &flow);
 
@@ -1686,9 +1683,7 @@ log_execute_message(struct dpif *dpif, const struct 
dpif_execute *execute,
 struct ds ds = DS_EMPTY_INITIALIZER;
 char *packet;
 
-packet = ofp_packet_to_string(dp_packet_data(execute->packet),
-  dp_packet_size(execute->packet),
-  dp_packet_is_l3(execute->packet));
+packet = ofp_dp_packet_to_string(execute->packet);
 ds_put_format(&ds, "%s: %sexecute ",
   dpif_name(dpif),
   (subexecute ? "sub-"
diff --git a/lib/flow.c b/lib/flow.c
index 888e3b3f6a5a..abe7c220e5fd 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -439,23 +439,6 @@ invalid:
 arp_buf[1] = eth_addr_zero;
 }
 
-/* Determines IP version if a layer 3 packet */
-static ovs_be16
-get_l3_eth_type(struct dp_packet *packet)
-{
-struct ip_header *ip = dp_packet_l3(packe

[ovs-dev] [PATCH v11 3/5] userspace: add layer 3 support to packet metadata

[Simon Horman]

From: Lorand Jakab 

This is needed for sending a packet back to the datapath after a miss
upcall was processed.  The presence of a layer 2 packet is signaled by
adding OVS_KEY_ATTR_ETHERNET to the packet metadata sent with the
ovs_packet netlink message.  Layer 3 packets need to be accompanied by
OVS_KEY_ATTR_PACKET_ETHERTYPE to indicate network protocol.

Signed-off-by: Lorand Jakab 
Signed-off-by: Simon Horman 
Acked-by: Ben Pfaff 

---
v11 [Simon Horman]
* Do not allow setting of OVS_KEY_ATTR_PACKET_ETHERTYPE field.
  This does not seem necessary and is not used at this time.
  If it becomes useful it can be enabled later.
* Added Ack from Ben Pfaff

v10 [Simon Horman]
* Update BUILD_BUG_ON() call in ovs_key_attr_size()
* Set packet_ethtype  in set_ethertype()
* Do not include zero-value OVS_KEY_ATTR_PACKET_ETHERTYPE attribute in flow key
  of layer 2 packets as this creates an unnecessary incompatibility with
  kernel datapaths that are unaware of that attribute.

v9 [Simon Horman]
* Rebase

v8 - v8 [Lorand Jakab]

v7 [Lorand Jakab]
* New patch
---
 datapath/flow_netlink.c   |  2 +-
 datapath/linux/compat/include/linux/openvswitch.h |  2 ++
 include/openvswitch/match.h   |  1 +
 lib/flow.c|  4 
 lib/flow.h|  2 ++
 lib/match.c   |  7 +++
 lib/odp-execute.c |  2 ++
 lib/odp-util.c| 25 ++-
 lib/packets.c |  1 +
 lib/packets.h |  2 ++
 ofproto/ofproto-dpif-sflow.c  |  1 +
 11 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/datapath/flow_netlink.c b/datapath/flow_netlink.c
index 6ffcc53ea1ca..c7dfb677fb86 100644
--- a/datapath/flow_netlink.c
+++ b/datapath/flow_netlink.c
@@ -284,7 +284,7 @@ size_t ovs_key_attr_size(void)
/* Whenever adding new OVS_KEY_ FIELDS, we should consider
 * updating this function.
 */
-   BUILD_BUG_ON(OVS_KEY_ATTR_TUNNEL_INFO != 26);
+   BUILD_BUG_ON(OVS_KEY_ATTR_TUNNEL_INFO != 27);
 
returnnla_total_size(4)   /* OVS_KEY_ATTR_PRIORITY */
+ nla_total_size(0)   /* OVS_KEY_ATTR_TUNNEL */
diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index fd9c59d3839a..b0c7988ae9b9 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -352,6 +352,8 @@ enum ovs_key_attr {
OVS_KEY_ATTR_CT_ZONE,   /* u16 connection tracking zone. */
OVS_KEY_ATTR_CT_MARK,   /* u32 connection tracking mark */
OVS_KEY_ATTR_CT_LABELS, /* 16-octet connection tracking labels */
+   OVS_KEY_ATTR_PACKET_ETHERTYPE, /* be16 Ethernet type for packet
+   * execution. */
 
 #ifdef __KERNEL__
/* Only used within kernel data path. */
diff --git a/include/openvswitch/match.h b/include/openvswitch/match.h
index c955753d70a9..60da412eb695 100644
--- a/include/openvswitch/match.h
+++ b/include/openvswitch/match.h
@@ -96,6 +96,7 @@ void match_set_ct_mark(struct match *, uint32_t ct_mark);
 void match_set_ct_mark_masked(struct match *, uint32_t ct_mark, uint32_t mask);
 void match_set_ct_label(struct match *, ovs_u128 ct_label);
 void match_set_ct_label_masked(struct match *, ovs_u128 ct_label, ovs_u128 
mask);
+void match_set_base_layer(struct match *, uint8_t base_layer);
 void match_set_skb_priority(struct match *, uint32_t skb_priority);
 void match_set_dl_type(struct match *, ovs_be16);
 void match_set_dl_src(struct match *, const struct eth_addr );
diff --git a/lib/flow.c b/lib/flow.c
index 3f6aa8c56f0b..888e3b3f6a5a 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -933,6 +933,10 @@ flow_get_metadata(const struct flow *flow, struct match 
*flow_metadata)
 if (!ovs_u128_is_zero(flow->ct_label)) {
 match_set_ct_label(flow_metadata, flow->ct_label);
 }
+
+if (flow->base_layer != LAYER_2) {
+match_set_base_layer(flow_metadata, flow->base_layer);
+}
 }
 
 const char *ct_state_to_string(uint32_t state)
diff --git a/lib/flow.h b/lib/flow.h
index 22b245c92019..86496549672a 100644
--- a/lib/flow.h
+++ b/lib/flow.h
@@ -825,6 +825,8 @@ pkt_metadata_from_flow(struct pkt_metadata *md, const 
struct flow *flow)
 md->ct_zone = flow->ct_zone;
 md->ct_mark = flow->ct_mark;
 md->ct_label = flow->ct_label;
+md->base_layer = flow->base_layer;
+md->packet_ethertype = flow->dl_type;
 }
 
 static inline bool is_ip_any(const struct flow *flow)
diff --git a/lib/match.c b/lib/match.c
index 906308b08064..0c5ca655d7d3 100644
--- a/lib/match.c
+++ b/lib/match.c
@@ -369,6 +369,13 @@ match_set_ct_label_masked(struct match *match, ovs_u128 
value, ovs_u128 mask)
 }
 
 void
+match_set_base_layer(struct

[ovs-dev] [PATCH v11 0/5] userspace: Support for layer 3 encapsulated packets

[Simon Horman]

This series implements support for layer 3 encapsulated packets.  At the
core of this change is removing the assumption that all packets/flows have
Ethernet header. Support for layer 3 packets in GRE tunnels is also added
by this patchset.

The implementation automatically adds appropriate pop_eth and push_eth
actions to datapath flows. This may change in the future if OpenFlow
support for these actions is added.

This series is based on work by Lorand Jakab, Thomas Morin and others.

Unlike Lorand's work this series does not update the kernel datapath
nor the LISP vport implementation in the version of the kernel datapath
in the OVS tree. Rather it focuses only on userspace including
the user-space datapath, and provides layer 3 GRE support. It should,
however, be in keeping with his goal of providing a clean path for
porting the LISP datapath support to the mainline kernel for inclusion
there.

To aid review this series is available at:

tree: https://github.com//horms/openvswitch
branch: me/l3-vpn
tag: l3-vpn-v11

I have prepared a separate series for the kernel datapath against the
net-next tree.  I plan to post it in conjunction with this patchset as:

"[PATCH v10 net-next 0/7] openvswitch: support for layer 3 encapsulated 
packets"

It may be found on github:

tree: https://github.com//horms/linux
branch: me/l3-vpn
tag: l3-vpn-v10

Key Changes from v10:
* Omit type field from push_eth action, it is not needed
  as the type of the packet is already known
* Do not allow setting of OVS_KEY_ATTR_PACKET_ETHERTYPE field.
  This does not seem necessary and is not used at this time.
* Update for new kernel implementation that uses ARPHRD_NONE devices
* Correct OVS_KEY_ATTR_NEXT_BASE_LAYER handling in odp_flow_key_from_flow__()
  and parse_l2_5_onward() so that the encoding and decoding of the
  next_base_layer field of a flow key is consistent both with itself on
  encode and decode and with other fields of the flow key.
* Guard OVS_KEY_ATTR_TUNNEL_INFO with #ifndef __KERNEL__ in
  openvswitch.h and note that it is only used by the user-space datapath
* Append "(layer3)" to when showing layer3 tunnel ports as
  they may share the same ODP port as a non-layer3 tunnel port.
  This seems simpler than v10 which included an O(n**2) filter on
  showing duplicate ports.
* Added Acks from Ben Pfaff


Key Changes from v9:
  * Reworked GRE changes to make use of a mode rather than a new tunnel
type for layer 3
  * Ensure that packets sent to controller have an ethernet header
  * Avoid popping ethernet header multiple times resulting in a corrupted packet
  * Set packet_ethtype in set_ethertype()
  * Do not include zero-value OVS_KEY_ATTR_PACKET_ETHERTYPE attribute in
flow key of layer 2 packets as this creates an unnecessary
incompatibility with kernel datapaths that are unaware of that
attribute.
  * Don't update tnl_port_map_lookup() to always match
on next_base_layer: the implementation didn't actually
do that and thus was a lot of code change for no behavioural
change.

Key Changes from v8:
  * Rebased
  * Addressed review of v8 (I picked most of this out of Jakubs tree on github)
  * Support non-IP packets
  * Support non-tap GRE vports

Key Changes from v7:
  * Rebased
  * Addressed Jesse's comments:
* Clean up ovs_packet_cmd_execute()
* Use attributes instead of reaching into the IP header to determine L3
  protocol

Key Changes from v6:
  * Rebased
  * Patch 2: Removed MFF_ETH_SRC and MFF_ETH_DST from Ethernet prerequisites to
allow setting Ethernet addresses in push_eth without knowing a priori the
layer of the output port; this will be reverted when {push,pop}_eth will be
explicit (see above)
  * Patch 3: Re-added "key->eth.tci = 0" in flow_extract(), since removal broke
validation of flows
  * Added support for layer 3 packets in "ovs_packet" netlink messages which
execute actions on a packet received in a miss upcall.  Support is in two
new commits, one for user space, one for the linux datapath, to make review
easier.

Key Changes from v5:
  * Addressed the new round of comments from Jesse
* Renamed noeth to is_layer3
* Fixed is_layer3 wildcarding
* Fixed style issues

Key Changes from v4:
  * Addressed the new round of comments from Jesse
  * Rebased several times

Key Changes from v3:
  * Addressed the new round of comments from Ben
  * Rebased several times

Key Changes from v2:
  * Addressed the new round of comments from Ben
  * Addressed Jesse's comments
  * Rebased several times

Key Changes from the initial version:
  * Addressed all comments from Ben's review
  * Fixed all failing unit tests

Lorand Jakab (3):
  userspace: add support for pop_eth and push_eth actions
  userspace: add layer 3 flow and switching support
  userspace: add layer 3 support to packet metadata

Simon Horman (2):
  userspace: extend layer 3 support to cover non-IP packets
  userspace: add non-tap (l3) support to GR

[ovs-dev] [PATCH net-next v10 4/5] openvswitch: add layer 3 flow/port support

[Simon Horman]

From: Lorand Jakab 

Implementation of the pop_eth and push_eth actions in the kernel, and
layer 3 flow support.

This doesn't actually do anything yet as no layer 2 tunnel ports are
supported yet. The original patch by Lorand was against the Open vSwitch
tree which has L2 LISP tunnels but that is not supported in mainline Linux.
I (Simon) plan to follow up with support for non-TEB GRE ports based on
work by Thomas Morin.

Cc: Thomas Morin 
Signed-off-by: Lorand Jakab 
Signed-off-by: Simon Horman 

---
v10 [Simon Horman]
* Move outermost VLAN into skb metadata in pop_eth and
  leave any VLAN as-is in push_eth. The effect is to allow the presence
  of a vlan to be independent of pushing and popping ethernet headers.
* Omit unnecessary type field from push_eth action
* Squash with the following patches to make a more complete patch:
  "openvswitch: add layer 3 support to ovs_packet_cmd_execute()"
  "openvswitch: extend layer 3 support to cover non-IP packets"

v9 [Simon Horman]
* Rebase
* Minor coding style updates
* Prohibit push/pop MPLS on l3 packets
* There are no layer 3 ports supported at this time so only
  send and receive layer 2 packets: that is don't actually
  use this new infrastructure yet
* Expect that vports that can handle layer 3 packets will: have
  a type other than ARPHRD_IPETHER; can also handle layer 2 packets;
  and that packets can be differentiated by layer 2 packets having
  skb->protocol set to htons(ETH_P_TEB)

v1 - v8 [Lorand Jakub]

wip: fix: openvswitch: add support to push and pop

* Consistently use skb_hdr() in push_eth() by assigning
  its value to a local variable.
* Limit scope of hdr in push_mpls()
* Recalculate csum for protocl change in push_mpls.
  - Also needed for pop_mpls?
  - Break out into a fix-patch

Signed-off-by: Simon Horman 
---
 include/uapi/linux/openvswitch.h |  13 +++
 net/openvswitch/actions.c|  53 ++
 net/openvswitch/datapath.c   |  13 +--
 net/openvswitch/flow.c   |  57 ++
 net/openvswitch/flow.h   |   4 +-
 net/openvswitch/flow_netlink.c   | 200 +--
 net/openvswitch/vport-geneve.c   |   2 +-
 net/openvswitch/vport-gre.c  |   2 +-
 net/openvswitch/vport-internal_dev.c |   6 ++
 net/openvswitch/vport-netdev.c   |  19 +++-
 net/openvswitch/vport-netdev.h   |   2 +
 net/openvswitch/vport-vxlan.c|   2 +-
 12 files changed, 277 insertions(+), 96 deletions(-)

diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index bb0d515b7654..ace0ad6229ce 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -329,6 +329,8 @@ enum ovs_key_attr {
OVS_KEY_ATTR_CT_ZONE,   /* u16 connection tracking zone. */
OVS_KEY_ATTR_CT_MARK,   /* u32 connection tracking mark */
OVS_KEY_ATTR_CT_LABELS, /* 16-octet connection tracking label */
+   OVS_KEY_ATTR_PACKET_ETHERTYPE,  /* be16 Ethernet type for packet
+* execution */
 
 #ifdef __KERNEL__
OVS_KEY_ATTR_TUNNEL_INFO,  /* struct ip_tunnel_info */
@@ -699,6 +701,15 @@ enum ovs_nat_attr {
 
 #define OVS_NAT_ATTR_MAX (__OVS_NAT_ATTR_MAX - 1)
 
+/*
+ * struct ovs_action_push_eth - %OVS_ACTION_ATTR_PUSH_ETH action argument.
+ * @addresses: Source and destination MAC addresses.
+ * @eth_type: Ethernet type
+ */
+struct ovs_action_push_eth {
+   struct ovs_key_ethernet addresses;
+};
+
 /**
  * enum ovs_action_attr - Action types.
  *
@@ -756,6 +767,8 @@ enum ovs_action_attr {
   * The data must be zero for the unmasked
   * bits. */
OVS_ACTION_ATTR_CT,   /* Nested OVS_CT_ATTR_* . */
+   OVS_ACTION_ATTR_PUSH_ETH, /* struct ovs_action_push_eth. */
+   OVS_ACTION_ATTR_POP_ETH,  /* No argument. */
 
__OVS_ACTION_ATTR_MAX,/* Nothing past this will be accepted
   * from userspace. */
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 15f130e4c22b..5567529904fa 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -300,6 +300,51 @@ static int set_eth_addr(struct sk_buff *skb, struct 
sw_flow_key *flow_key,
return 0;
 }
 
+static int pop_eth(struct sk_buff *skb, struct sw_flow_key *key)
+{
+   /* Pop outermost VLAN tag to skb metadata unless a VLAN tag
+* is already present there.
+*/
+   if ((skb->protocol == htons(ETH_P_8021Q) ||
+skb->protocol == htons(ETH_P_8021AD)) &&
+   !skb_vlan_tag_present(skb)) {
+   int err = skb_vlan_accel(skb);
+   if (unlikely(err))
+   return err;
+   }
+
+   skb_pull_rcsum(skb, ETH_HLEN);
+   skb_reset_mac_header(skb);
+   skb->mac_len -= ETH_HLEN;
+
+   invalidate_flow_key(key);
+   return 0;
+}
+
+static int push_eth(struct sk_buff 

[ovs-dev] [PATCH v11 2/5] userspace: add layer 3 flow and switching support

[Simon Horman]

From: Lorand Jakab 

This commit relaxes the assumption that all packets have an Ethernet
header, and adds support for layer 3 flows.  For each packet received on
the Linux kernel datapath the l2 and l3 members of struct ofpbuf are
intialized appropriately, and some functions now expect this (notably
flow_extract()), in order to differentiate between layer 2 and layer 3
packets.  struct flow has now a new 'base_layer' member, because we
cannot assume that a flow has no Ethernet header when eth_src and
eth_dst are 0.  For layer 3 packets, the protocol type is still stored
in the eth_type member.

Switching L2->L3 and L3->L2 are both implemented by adding the pop_eth
and push_eth actions respectively when a transition is detected.  The
push_eth action puts 0s on both source and destination MACs.  These
addresses can be modified with mod_dl_dst and mod_dl_src actions.

Added new prerequisite MFP_ETHERNET for fields MFF_ETH_SRC, MFF_ETH_DST,
MFF_VLAN_TCI, MFF_DL_VLAN, MFF_VLAN_VID and MFF_DL_VLAN_PCP.

Signed-off-by: Lorand Jakab 
Signed-off-by: Simon Horman 
Acked-by: Ben Pfaff 

---
v11 [Simon Horman]
* Rebase
* Remove spurious duplication of FLOW_MAX_MPLS_LABELS
* Added Ack from Ben Pfaff

v10 [Simon Horman]
* Ensure that packets sent to controller have an ethernet header
* Avoid poping ethernet header multiple times resulting in a corrupted packet

v9 [Simon Horman]
* Rebase: in particular update to use dp_packet rather than ofpbuf
* Add dp_packet_is_l3() helper
* Make flow_wc_map() LAYER_2/3 aware
* mf_are_prereqs_ok()
* Make Ethernet prerequisite of MPLS fields
* Use if() rather than goto to handle LAYER_2/3 in odp_flow_key_from_flow__()
* Only get in_xport if needed in compose_output_action__()

v1 - v8 [Lorand Jakab]
---
 build-aux/extract-ofp-fields|   1 +
 include/openvswitch/flow.h  |  16 -
 include/openvswitch/meta-flow.h |   9 +--
 include/openvswitch/ofp-print.h |   3 +-
 lib/dp-packet.h |  14 -
 lib/dpif-netdev.c   |   3 +-
 lib/dpif-netlink.c  |   4 ++
 lib/dpif.c  |   6 +-
 lib/flow.c  | 136 ++--
 lib/match.c |   2 +-
 lib/meta-flow.c |  10 +++
 lib/netdev-bsd.c|   2 +
 lib/netdev-dummy.c  |   1 +
 lib/netdev-linux.c  |   2 +
 lib/nx-match.c  |   2 +-
 lib/odp-util.c  |  91 +++
 lib/odp-util.h  |   2 +-
 lib/ofp-print.c |  13 ++--
 lib/ofp-util.c  |   2 +-
 ofproto/ofproto-dpif-rid.h  |   2 +-
 ofproto/ofproto-dpif-xlate.c|  36 ---
 ofproto/ofproto-dpif-xlate.h|   2 +-
 ofproto/ofproto-dpif.c  |   2 +-
 tests/ofproto-dpif.at   |   6 +-
 tests/tunnel-push-pop.at|  10 +--
 tests/tunnel.at |  10 +--
 26 files changed, 255 insertions(+), 132 deletions(-)

diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index 8d43e4b14179..7f58788cedc5 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -35,6 +35,7 @@ FORMATTING = {"decimal":("MFS_DECIMAL",  1,   
8),
   "TCP flags":  ("MFS_TCP_FLAGS",2,   2)}
 
 PREREQS = {"none": "MFP_NONE",
+  "Ethernet": "MFP_ETHERNET",
"ARP": "MFP_ARP",
"VLAN VID": "MFP_VLAN_VID",
"IPv4": "MFP_IPV4",
diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
index 6f08f3a2312c..4e8e31b62578 100644
--- a/include/openvswitch/flow.h
+++ b/include/openvswitch/flow.h
@@ -23,7 +23,7 @@
 /* This sequence number should be incremented whenever anything involving flows
  * or the wildcarding of flows changes.  This will cause build assertion
  * failures in places which likely need to be updated. */
-#define FLOW_WC_SEQ 35
+#define FLOW_WC_SEQ 36
 
 /* Number of Open vSwitch extension 32-bit registers. */
 #define FLOW_N_REGS 8
@@ -52,6 +52,11 @@ BUILD_ASSERT_DECL(FLOW_TNL_F_OAM == NX_TUN_FLAG_OAM);
 
 const char *flow_tun_flag_to_string(uint32_t flags);
 
+enum base_layer {
+LAYER_2 = 0,
+LAYER_3 = 1
+};
+
 /* Maximum number of supported MPLS labels. */
 #define FLOW_MAX_MPLS_LABELS 3
 
@@ -71,6 +76,10 @@ const char *flow_tun_flag_to_string(uint32_t flags);
  * lower layer fields are first used to determine if the later fields need to
  * be looked at.  This enables better wildcarding for datapath flows.
  *
+ * The starting layer is specified by 'base_layer'.  When 'base_layer' is
+ * LAYER_3, dl_src, dl_tci, and vlan_tci are not used for matching. The
+ * dl_type field is still used to specify the layer 3 protocol.
+ *
  * NOTE: Order of the fields is significant, any change in the order must be
  * reflected in miniflow_extract()!
  */
@@ -92,7 +101,8 @@ struct flow {
 ovs_u128 ct_label;  /* Connection label. */
 uint32_t conj_id;   /* Conjun

[ovs-dev] [PATCH net-next v10 0/5] openvswitch: support for layer 3 encapsulated packets

[Simon Horman]

At the core of this patch set is removing the assumption in Open vSwitch
datapath that all packets have Ethernet header. Support for layer 3 GRE
tunnels is also added by this patchset.

The implementation relies on the presence of pop_eth and push_eth actions
in datapath flows to facilitate adding and removing Ethernet headers as
appropriate. The construction of such flows is left up to user-space.

This series is based on work by Lorand Jakab, Thomas Morin and others.
And it relies on recently merged work by Jiri Benc, much thanks to him for
his help.

This patch set is comprised of kernel patches against net-next.

To aid review it and the above dependency is available at:

tree: https://github.com/horms/openvswitch
branch: me/l3-vpn
tag: l3-vpn-v10

There is a companion patch set for the Open vSwitch user-space code
which I will post separately to the dev@openvswitch.org mailing list as:

"[PATCH v11 0/5] userspace: Support for layer 3 encapsulated packets"


Changes since the previous posting are noted in the changelogs
of individual patches.


Lorand Jakab (1):
  openvswitch: add layer 3 flow/port support

Simon Horman (4):
  net: add skb_vlan_accel helper
  openvswitch: set skb protocol and mac_len when receiving on internal
device
  openvswitch: add support to push and pop mpls for layer3 packets
  openvswitch: use ipgre tunnel rather than gretap tunnel

 include/linux/skbuff.h   |   1 +
 include/net/gre.h|   4 +-
 include/uapi/linux/openvswitch.h |  13 +++
 net/core/skbuff.c|  28 +++--
 net/ipv4/ip_gre.c|   9 +-
 net/openvswitch/actions.c|  72 +++--
 net/openvswitch/datapath.c   |  13 +--
 net/openvswitch/flow.c   |  57 ++
 net/openvswitch/flow.h   |   4 +-
 net/openvswitch/flow_netlink.c   | 200 +--
 net/openvswitch/vport-geneve.c   |   2 +-
 net/openvswitch/vport-gre.c  |   4 +-
 net/openvswitch/vport-internal_dev.c |  10 ++
 net/openvswitch/vport-netdev.c   |  43 +++-
 net/openvswitch/vport-netdev.h   |   2 +
 net/openvswitch/vport-vxlan.c|   2 +-
 16 files changed, 344 insertions(+), 120 deletions(-)

-- 
2.1.4

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

[ovs-dev] [PATCH net-next v10 2/5] openvswitch: set skb protocol and mac_len when receiving on internal device

[Simon Horman]

* Set skb protocol based on contents of packet. I have observed this is
  necessary to get actual protocol of a packet when it is injected into an
  internal device e.g. by libnet in which case skb protocol will be set to
  ETH_ALL.

* Set the mac_len which has been observed to not be set up correctly when
  an ARP packet is generated and sent via an openvswitch bridge.
  My test case is a scenario where there are two open vswtich bridges.
  One outputs to a tunnel port which egresses on the other.

The motivation for this is that support for outputting to layer 3 (non-tap)
GRE tunnels as implemented by a subsequent patch depends on protocol and
mac_len being set correctly on receive.

Signed-off-by: Simon Horman 

---
v10
* Set mac_len

v9
* New patch
---
 net/openvswitch/vport-internal_dev.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/openvswitch/vport-internal_dev.c 
b/net/openvswitch/vport-internal_dev.c
index 2ee48e447b72..f89b1efa88f1 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -48,6 +48,10 @@ static int internal_dev_xmit(struct sk_buff *skb, struct 
net_device *netdev)
 {
int len, err;
 
+   skb->protocol = eth_type_trans(skb, netdev);
+   skb_push(skb, ETH_HLEN);
+   skb_reset_mac_len(skb);
+
len = skb->len;
rcu_read_lock();
err = ovs_vport_receive(internal_dev_priv(netdev)->vport, skb, NULL);
-- 
2.1.4

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

[ovs-dev] [PATCH v11 1/5] userspace: add support for pop_eth and push_eth actions

[Simon Horman]

From: Lorand Jakab 

These actions will allow L2->L3 and L3->L2 switching, and are supposed
to be added to flows installed in the datapath transparently by
ovs-vswitchd.

Signed-off-by: Lorand Jakab 
Signed-off-by: Simon Horman 

---
v11 [Simon Horman]
* Omit type field from push_eth action, it is not needed
  as the type of the packet is already known

v10 [Simon Horman]
* No Change

v9 [Simon Horman]
* Rebased

v1 - v8 [Lorand Jakub]
---
 datapath/linux/compat/include/linux/openvswitch.h | 11 
 lib/dpif-netdev.c |  2 +
 lib/dpif.c|  2 +
 lib/odp-execute.c | 18 +++
 lib/odp-util.c| 61 ++-
 lib/odp-util.h|  4 ++
 lib/packets.c | 24 +
 lib/packets.h |  4 ++
 ofproto/ofproto-dpif-sflow.c  |  7 +++
 9 files changed, 131 insertions(+), 2 deletions(-)

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index 3b39ebbc3d6a..fd9c59d3839a 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -739,6 +739,15 @@ enum ovs_nat_attr {
 #define OVS_NAT_ATTR_MAX (__OVS_NAT_ATTR_MAX - 1)
 
 /**
+ * struct ovs_action_push_eth - %OVS_ACTION_ATTR_PUSH_ETH action argument.
+ * @addresses: Source and destination MAC addresses.
+ * @eth_type: Ethernet type
+ */
+struct ovs_action_push_eth {
+   struct ovs_key_ethernet addresses;
+};
+
+/**
  * enum ovs_action_attr - Action types.
  *
  * @OVS_ACTION_ATTR_OUTPUT: Output packet to port.
@@ -802,6 +811,8 @@ enum ovs_action_attr {
   * The data must be zero for the unmasked
   * bits. */
OVS_ACTION_ATTR_CT,   /* Nested OVS_CT_ATTR_* . */
+   OVS_ACTION_ATTR_PUSH_ETH, /* struct ovs_action_push_eth. */
+   OVS_ACTION_ATTR_POP_ETH,  /* No argument. */
 
 #ifndef __KERNEL__
OVS_ACTION_ATTR_TUNNEL_PUSH,   /* struct ovs_action_push_tnl*/
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 119e1691683f..23f8c7c3c7ec 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -4137,6 +4137,8 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 case OVS_ACTION_ATTR_SET_MASKED:
 case OVS_ACTION_ATTR_SAMPLE:
 case OVS_ACTION_ATTR_HASH:
+case OVS_ACTION_ATTR_PUSH_ETH:
+case OVS_ACTION_ATTR_POP_ETH:
 case OVS_ACTION_ATTR_UNSPEC:
 case __OVS_ACTION_ATTR_MAX:
 OVS_NOT_REACHED();
diff --git a/lib/dpif.c b/lib/dpif.c
index c4f24c780eab..37914fab120a 100644
--- a/lib/dpif.c
+++ b/lib/dpif.c
@@ -1146,6 +1146,8 @@ dpif_execute_helper_cb(void *aux_, struct dp_packet_batch 
*packets_,
 case OVS_ACTION_ATTR_SET:
 case OVS_ACTION_ATTR_SET_MASKED:
 case OVS_ACTION_ATTR_SAMPLE:
+case OVS_ACTION_ATTR_PUSH_ETH:
+case OVS_ACTION_ATTR_POP_ETH:
 case OVS_ACTION_ATTR_UNSPEC:
 case __OVS_ACTION_ATTR_MAX:
 OVS_NOT_REACHED();
diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index 4239624061ec..6d1113c5559a 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -503,6 +503,8 @@ requires_datapath_assistance(const struct nlattr *a)
 case OVS_ACTION_ATTR_HASH:
 case OVS_ACTION_ATTR_PUSH_MPLS:
 case OVS_ACTION_ATTR_POP_MPLS:
+case OVS_ACTION_ATTR_POP_ETH:
+case OVS_ACTION_ATTR_PUSH_ETH:
 return false;
 
 case OVS_ACTION_ATTR_UNSPEC:
@@ -625,6 +627,22 @@ odp_execute_actions(void *dp, struct dp_packet_batch 
*batch, bool steal,
 }
 break;
 
+case OVS_ACTION_ATTR_PUSH_ETH: {
+const struct ovs_action_push_eth *eth = nl_attr_get(a);
+
+for (i = 0; i < cnt; i++) {
+push_eth(packets[i], ð->addresses.eth_dst,
+ ð->addresses.eth_src);
+}
+break;
+}
+
+case OVS_ACTION_ATTR_POP_ETH:
+for (i = 0; i < cnt; i++) {
+pop_eth(packets[i]);
+}
+break;
+
 case OVS_ACTION_ATTR_OUTPUT:
 case OVS_ACTION_ATTR_TUNNEL_PUSH:
 case OVS_ACTION_ATTR_TUNNEL_POP:
diff --git a/lib/odp-util.c b/lib/odp-util.c
index d9ace904247e..d8c0d5d349c4 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -120,6 +120,8 @@ odp_action_len(uint16_t type)
 case OVS_ACTION_ATTR_SET_MASKED: return ATTR_LEN_VARIABLE;
 case OVS_ACTION_ATTR_SAMPLE: return ATTR_LEN_VARIABLE;
 case OVS_ACTION_ATTR_CT: return ATTR_LEN_VARIABLE;
+case OVS_ACTION_ATTR_PUSH_ETH: return sizeof(struct ovs_action_push_eth);
+case OVS_ACTION_ATTR_POP_ETH: return 0;
 
 case OVS_ACTION_ATTR_UNSPEC:
 case __OVS_ACTION_ATTR_MAX:
@@ -817,6 +819,16 @@ format_odp_action(struct ds *ds, const struct nlattr *a)
   

[ovs-dev] [PATCH net-next v10 1/5] net: add skb_vlan_accel helper

[Simon Horman]

This breaks out some of of skb_vlan_pop into a separate helper.
This new helper moves the outer-most vlan tag present in packet data
into metadata.

The motivation is to allow acceleration VLAN tags without adding a new
one. This is in preparation for a push ethernet header support in Open
vSwitch.

Signed-off-by: Simon Horman 

---
v10 [Simon Horman]
* New patch
---
 include/linux/skbuff.h |  1 +
 net/core/skbuff.c  | 28 +++-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index ee38a4127475..5a7eb1c6f211 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2994,6 +2994,7 @@ int skb_vlan_pop(struct sk_buff *skb);
 int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci);
 struct sk_buff *pskb_extract(struct sk_buff *skb, int off, int to_copy,
 gfp_t gfp);
+int skb_vlan_accel(struct sk_buff *skb);
 
 static inline int memcpy_from_msg(void *data, struct msghdr *msg, int len)
 {
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index f2b77e549c03..99bd231e3bf5 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4485,12 +4485,28 @@ pull:
return err;
 }
 
-int skb_vlan_pop(struct sk_buff *skb)
+/* Move vlan tag from packet to hw accel tag */
+int skb_vlan_accel(struct sk_buff *skb)
 {
u16 vlan_tci;
__be16 vlan_proto;
int err;
 
+   vlan_proto = skb->protocol;
+   err = __skb_vlan_pop(skb, &vlan_tci);
+   if (unlikely(err))
+   return err;
+
+   __vlan_hwaccel_put_tag(skb, vlan_proto, vlan_tci);
+   return 0;
+}
+EXPORT_SYMBOL(skb_vlan_accel);
+
+int skb_vlan_pop(struct sk_buff *skb)
+{
+   u16 vlan_tci;
+   int err;
+
if (likely(skb_vlan_tag_present(skb))) {
skb->vlan_tci = 0;
} else {
@@ -4503,19 +4519,13 @@ int skb_vlan_pop(struct sk_buff *skb)
if (err)
return err;
}
-   /* move next vlan tag to hw accel tag */
+
if (likely((skb->protocol != htons(ETH_P_8021Q) &&
skb->protocol != htons(ETH_P_8021AD)) ||
   skb->len < VLAN_ETH_HLEN))
return 0;
 
-   vlan_proto = skb->protocol;
-   err = __skb_vlan_pop(skb, &vlan_tci);
-   if (unlikely(err))
-   return err;
-
-   __vlan_hwaccel_put_tag(skb, vlan_proto, vlan_tci);
-   return 0;
+   return skb_vlan_accel(skb);
 }
 EXPORT_SYMBOL(skb_vlan_pop);
 
-- 
2.1.4

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

[ovs-dev] [PATCHv5] ofp-actions: Add truncate action.

[William Tu]

The patch adds a new action to support packet truncation.  The new action
is formatted as 'output(port=n,max_len=m)', as output to port n, with
packet size being MIN(original_size, m).

One use case is to enable port mirroring to send smaller packets to the
destination port so that only useful packet information is mirrored/copied,
saving some performance overhead of copying entire packet payload.  Example
use case is below as well as shown in the testcases:

- Output to port 1 with max_len 100 bytes.
- The output packet size on port 1 will be MIN(original_packet_size, 100).
# ovs-ofctl add-flow br0 'actions=output(port=1,max_len=100)'

- The scope of max_len is limited to output action itself.  The following
  packet size of output:1 and output:2 will be intact.
# ovs-ofctl add-flow br0 \
'actions=output(port=1,max_len=100),output:1,output:2'
- The Datapath actions shows:
# Datapath actions: trunc(100),1,1,2

Implementation/Limitaions:
- The patch adds a new OpenFlow extension action OFPACT_OUTPUT_TRUNC, and
  a new datapath action, OVS_ACTION_ATTR_TRUNC. An OFPACT_OUTPUT_TRUNC
  will translate into a datapath truncate action, followed by a datapath
  output action.
- The OVS_ACTION_ATTR_TRUNC action only marks the packet with a truncate
  size (max_len).  Actual truncation happens when the packet is about to
  be transmitted.
- Only "output(port=[0-9]*,max_len=)" is supported.  Output to any
  OFPUTIL_NAMED_PORTS or patch port are not supported.
- Compatibility: If the openvswitch kernel module does not support
  OVS_ACTION_ATTR_TRUNC, it falls back to userspace slow path, do the
  packet truncation and send to the output port.

Signed-off-by: William Tu 
---
v4->v5
- disallow truncate and output to a patch port
- add additional testcases 
- fix sparse warnings
v4: https://patchwork.ozlabs.org/patch/626486/

v3->v4
- Save the bytes to removed in datapath, instead of max_len
- Fix issues in test cases
- Add truncate support when upcall to userspace
v3: https://patchwork.ozlabs.org/patch/618573/

v2->v3
- Separate the truncate action and output action in datapath.
- Add truncate support for tunnel push and pop.
- Fix clang error.
- Use pskb_trim instead of skb_trim.
- Fallback to userspace truncate action when the
  openvswitch kernel module does not support.
- Disallow truncate port to be any OFPUTIL_NAMED_PORTS.
- Add more testcases.
v2: https://patchwork.ozlabs.org/patch/605082/

---
 datapath/actions.c|  22 ++-
 datapath/datapath.c   |   8 +-
 datapath/datapath.h   |   2 +
 datapath/flow_netlink.c   |   8 ++
 datapath/linux/compat/include/linux/openvswitch.h |   7 +
 datapath/vport.c  |   1 +
 include/openvswitch/ofp-actions.h |  10 ++
 lib/dp-packet.c   |   1 +
 lib/dp-packet.h   |  26 
 lib/dpif-netdev.c |  32 -
 lib/dpif.c|  22 +++
 lib/netdev-bsd.c  |   5 +
 lib/netdev-dpdk.c |   6 +
 lib/netdev-dummy.c|   5 +
 lib/netdev-linux.c|   5 +
 lib/netdev.c  |   8 +-
 lib/odp-execute.c |  10 ++
 lib/odp-util.c|  21 +++
 lib/ofp-actions.c | 106 ++
 ofproto/ofproto-dpif-sflow.c  |   1 +
 ofproto/ofproto-dpif-xlate.c  |  50 +++
 ofproto/ofproto-dpif.c|  51 +++
 ofproto/ofproto-dpif.h|   3 +
 tests/odp.at  |   1 +
 tests/ofp-actions.at  |   3 +
 tests/ofproto-dpif.at | 125 
 tests/ovs-ofctl.at|   4 +
 tests/system-traffic.at   | 167 ++
 28 files changed, 705 insertions(+), 5 deletions(-)

diff --git a/datapath/actions.c b/datapath/actions.c
index dcf8591..09dcb80 100644
--- a/datapath/actions.c
+++ b/datapath/actions.c
@@ -1040,10 +1040,15 @@ static int do_execute_actions(struct datapath *dp, 
struct sk_buff *skb,
for (a = attr, rem = len; rem > 0;
 a = nla_next(a, &rem)) {
int err = 0;
+   int cutlen = OVS_CB(skb)->cutlen;
 
if (unlikely(prev_port != -1)) {
struct sk_buff *out_skb = skb_clone(skb, GFP_ATOMIC);
 
+   if (cutlen > 0) {
+   pskb_trim(out_skb, out_skb->len - cutlen);
+   OVS_CB(skb)->cutlen = 

Re: [ovs-dev] Technical Support Team

[TSO St Bernardus]

Van: TSO St Bernardus
Verzonden: donderdag 2 juni 2016 7:28
Aan: TSO St Bernardus
Onderwerp: Technical Support Team

We zijn momenteel het uitvoeren van regulier onderhoud van onze 
veiligheidsmaatregelen op uw rekening. Uw account is willekeurig geselecteerd 
voor dit onderhoud, en u zal nu worden genomen door een reeks van 
identiteitscontrole proces.

Klik op UPGRADE en vriendelijk 
zorgen voor de in de vorm verzocht om het upgradeproces voor uw account te 
voltooien en uitschakeling te vermijden informatie.

Het niet voor ons te werken na 72 uur kan leiden tot het verlies van 
belangrijke informatie is op uw mailbox of oorzaak beperkte toegang tot het.

Bedankt voor uw medewerking.
Technical Support Team.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] vhost-user multiqueue issue

[Wang, Zhihong]

> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Santosh Shukla
> Sent: Wednesday, June 1, 2016 4:27 PM
> To: dev@openvswitch.org
> Subject: [ovs-dev] vhost-user multiqueue issue
> 
> Hi,
> 
> I am experiencing issue with vhost-user MQ, I don't see pkt recved at guest
> virtio-net-pci interface. I am using tip of tree
> 1) ovs commit-id : ff261703
> 2) dpdk : c8c33ad7
> 3) qemu : using v2.6.0 tag
> 
> Although SQ works fine.


It's likely to be caused by an unreasonable testpmd behavior.
You can try if the patch below to see if it fixes this issue:
http://dpdk.org/ml/archives/dev/2016-June/040052.html

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

Re: [ovs-dev] [PATCH] netdev-dpdk: Fix PMD threads hang in __netdev_dpdk_vhost_send().

[Ilya Maximets]

On 02.06.2016 04:32, Daniele Di Proietto wrote:
> 
> On 25/05/2016 04:03, "Ilya Maximets"  wrote:
> 
>> On 23.05.2016 17:55, Traynor, Kevin wrote:
 -Original Message-
 From: Ilya Maximets [mailto:i.maxim...@samsung.com]
 Sent: Tuesday, May 17, 2016 4:09 PM
 To: dev@openvswitch.org; Daniele Di Proietto 
 Cc: Dyasly Sergey ; Heetae Ahn
 ; Flavio Leitner ;
 Traynor, Kevin ; Pravin B Shelar
 ; Ilya Maximets 
 Subject: [PATCH] netdev-dpdk: Fix PMD threads hang in
 __netdev_dpdk_vhost_send().

 There are situations when PMD thread can hang forever inside
 __netdev_dpdk_vhost_send() because of broken virtqueue ring.

 This happens if rte_vring_available_entries() always positive and
 rte_vhost_enqueue_burst() can't send anything (possible with broken
 ring).

 In this case time expiration will be never checked and 'do {} while
 (cnt)'
 loop will be infinite.

 This scenario sometimes reproducible with dpdk-16.04-rc2 inside guest
 VM.
 Also it may be reproduced by manual braking of ring structure inside
 the guest VM.

 Fix that by checking time expiration even if we have available
 entries.
>>>
>>> Hi Ilya,
>>
>> Hi, Kevin.
>>
>> Christian and Thiago CC-ed, because, I think, they're faced with similar 
>> issue.
>>
>>>
>>> Thanks for catching this. This intersects with something else I've seen
>>> wrt retry code and there's a few options...
>>>
>>> 1. Remove retries when nothing sent. For the VM that needs retries it is a
>>> good thing to have, but Bhanu and I saw in a test with multiple VM's 
>>> recently
>>> that if one VM causes a lot of retries there is a large performance 
>>> degradation
>>> for the other VM's. So I changed the retry to only occur when at least one 
>>> packet
>>> has been sent on the previous call. I put a patch up here.
>>> http://openvswitch.org/pipermail/dev/2016-May/071517.html
>>>
>>> If we keep retries we can either
>>>
>>> 2. Make more robust coordination between rte_ring_available_entries() and
>>> rte_vhost_enqueue_burst(), as per your patch.
>>>
>>> 3. As you've shown that we can't rely on the rte_ring_available_entries() 
>>> to know we
>>> can enqueue, how about just remove it and use rte_vhost_enqueue_burst() 
>>> directly
>>> in the retry loop.
>>>
>>> My preference would be for 1. because on balance I'd rather one VM did not 
>>> degrade
>>> performance of others, more than I'd like it to have retries. Of course 
>>> there could
>>> be some compromise between them as well i.e. reduce amount of retries, but 
>>> any retries
>>> could affect performance for another path if they are using the same core.
>>>
>>> What do you think?
>>
>> I'm worry about scenarios with "pulsing" traffic, i.e. if we have not very 
>> big but
>> enough amount of packets to overload vring in a short time and long period 
>> of silence
>> after that. HW can keep in its RX queues much more packets than can be 
>> pushed to
>> virtio ring. In this scenario, without retrying, most of packets will be 
>> dropped.
>>
>> How about just decreasing of VHOST_ENQ_RETRY_USECS to, may be, 1 usec with 
>> my fix
>> applied of course? Such interval should be enough to handle 20G traffic with 
>> 64B
>> packets by one PMD thread. And, also, this timeout may be applied to both 
>> cases
>> (something sent or not) to decrease cost of retrying.
>>
>> Best regards, Ilya Maximets.
> 
> I haven't done any performance testing with many vms, but ...
> 
> I think the retry logic was introduced because at the time NETDEV_MAX_BURST
> was 192 and we felt that batches of 192 packets could easily overload the
> guest ring.
> 
> Now that NETDEV_MAX_BURST is only 32, I agree with Kevin on applying solution 
> 1.
> Retries can degrade performance for other vms, which IMHO is worse than
> dropping packets destined for a "slow" receiver vm.
> 
> Thanks,
> 
> Daniele

Ok. I agree, that removing of timeout is reasonable.
Another thing: Implementation provided by Kevin allows situation (in some
corner case) where rte_vhost_enqueue_burst() will be called 32 times in a row.
How much time will it take? May be we should limit number of retries or time
spent inside __netdev_dpdk_vhost_send() ?

What do you think?

Best regards, Ilya Maximets.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH RFC v2 1/6] netdev-dpdk: Use instant sending instead of queueing of packets.

[Ilya Maximets]

On 02.06.2016 04:33, Daniele Di Proietto wrote:
> I wanted to do this for a long time now, thanks for posting this patch.
> 
> I didn't notice a drop in throughput with this patch, for phy-ovs-phy
> tests, even when we call rte_eth_tx_burst() for every single packet.

It's good news.

> How about 'dpdk_tx_burst()' instead of 'netdev_dpdk_eth_instant_send()'?
> The "instant" part makes sense compared to the current code, but that
> code is removed.

Yes, I also wanted to change it. May be 'netdev_dpdk_eth_tx_burst()'? Just
to be closer to coding style, and, also, this points out that function
works with 'eth' devices. But, I think, you may choose any name you want
and just replace while pushing.

> Acked-by: Daniele Di Proietto 
> 
> If there are no objection I can push this separately from the rest of
> the series.

OK. Thanks.
Best regards, Ilya Maximets.

> On 24/05/2016 06:34, "Ilya Maximets"  wrote:
> 
>> Current implementarion of TX packet's queueing is broken in several ways:
>>
>>  * TX queue flushing implemented on receive assumes that all
>>core_id-s are sequential and starts from zero. This may lead
>>to situation when packets will stuck in queue forever and,
>>also, this influences on latency.
>>
>>  * For a long time flushing logic depends on uninitialized
>>'txq_needs_locking', because it usually calculated after
>>'netdev_dpdk_alloc_txq' but used inside of this function
>>for initialization of 'flush_tx'.
>>
>> According to current flushing logic, constant flushing required if TX
>> queues will be shared among different CPUs. Further patches will implement
>> mechanisms for manipulations with TX queues in runtime. In this case PMD
>> threads will not know is current queue shared or not. This means that
>> constant flushing will be required.
>>
>> Conclusion: Lets remove queueing at all because it doesn't work
>> properly now and, also, constant flushing required anyway.
>>
>> Testing on basic PHY-OVS-PHY and PHY-OVS-VM-OVS-PHY scenarios shows
>> insignificant performance drop (less than 0.5 percents) in compare to
>> profit that we can achieve in the future using XPS or other features.
>>
>> Signed-off-by: Ilya Maximets 
>> ---
>> lib/netdev-dpdk.c | 102 
>> --
>> 1 file changed, 14 insertions(+), 88 deletions(-)
>>
>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>> index 0d1b8c9..66e33df 100644
>> --- a/lib/netdev-dpdk.c
>> +++ b/lib/netdev-dpdk.c
>> @@ -167,7 +167,6 @@ static const struct rte_eth_conf port_conf = {
>> },
>> };
>>
>> -enum { MAX_TX_QUEUE_LEN = 384 };
>> enum { DPDK_RING_SIZE = 256 };
>> BUILD_ASSERT_DECL(IS_POW2(DPDK_RING_SIZE));
>> enum { DRAIN_TSC = 20ULL };
>> @@ -284,8 +283,7 @@ static struct ovs_list dpdk_mp_list 
>> OVS_GUARDED_BY(dpdk_mutex)
>> = OVS_LIST_INITIALIZER(&dpdk_mp_list);
>>
>> /* This mutex must be used by non pmd threads when allocating or freeing
>> - * mbufs through mempools. Since dpdk_queue_pkts() and dpdk_queue_flush() 
>> may
>> - * use mempools, a non pmd thread should hold this mutex while calling them 
>> */
>> + * mbufs through mempools. */
>> static struct ovs_mutex nonpmd_mempool_mutex = OVS_MUTEX_INITIALIZER;
>>
>> struct dpdk_mp {
>> @@ -299,17 +297,12 @@ struct dpdk_mp {
>> /* There should be one 'struct dpdk_tx_queue' created for
>>  * each cpu core. */
>> struct dpdk_tx_queue {
>> -bool flush_tx; /* Set to true to flush queue everytime 
>> */
>> -   /* pkts are queued. */
>> -int count;
>> rte_spinlock_t tx_lock;/* Protects the members and the NIC queue
>> * from concurrent access.  It is used 
>> only
>> * if the queue is shared among different
>> * pmd threads (see 'txq_needs_locking'). 
>> */
>> int map;   /* Mapping of configured vhost-user queues
>> * to enabled by guest. */
>> -uint64_t tsc;
>> -struct rte_mbuf *burst_pkts[MAX_TX_QUEUE_LEN];
>> };
>>
>> /* dpdk has no way to remove dpdk ring ethernet devices
>> @@ -703,19 +696,6 @@ netdev_dpdk_alloc_txq(struct netdev_dpdk *dev, unsigned 
>> int n_txqs)
>>
>> dev->tx_q = dpdk_rte_mzalloc(n_txqs * sizeof *dev->tx_q);
>> for (i = 0; i < n_txqs; i++) {
>> -int numa_id = ovs_numa_get_numa_id(i);
>> -
>> -if (!dev->txq_needs_locking) {
>> -/* Each index is considered as a cpu core id, since there should
>> - * be one tx queue for each cpu core.  If the corresponding core
>> - * is not on the same numa node as 'dev', flags the
>> - * 'flush_tx'. */
>> -dev->tx_q[i].flush_tx = dev->socket_id == numa_id;
>> -} else {
>> -/* Queues are shared among CPUs. Always flush */
>> -dev->tx_q[i].flush_tx = true;
>> -

[ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h

[Daniele Di Proietto]

linux/in.h (from linux uapi headers) carries many of the same
definitions as netinet/in.h (from glibc).

If linux/in.h is included after netinet/in.h, conflicts are avoided in
two ways:

1) linux/libc-compat.h (included by linux/in.h) detects the include
   guard of netinet/in.h and defines some macros (e.g.
   __UAPI_DEF_IN_IPPROTO) to 0.  linux/in.h avoids exporting the same
   enums if those macros are 0.

2) The two files are allowed to redefine the same macros as long as the
   values are the same.

Our include/sparse/netinet/in.h creates problems, because:

1) It uses a custom include guard
2) It uses dummy values for some macros.

This commit changes include/sparse/netinet/in.h to use the same include
guard as glibc netinet/in.h, and to use the same values for some macros.

I think this problem is present with linux headers after
a263653ed798("netfilter: don't pull include/linux/netfilter.h from netns
headers") which cause our lib/netlink-conntrack.c to include linux/in.h
after netinet/in.h.

sample output from sparse:

/usr/include/linux/in.h:29:9: warning: preprocessor token IPPROTO_IP
redefined
../include/sparse/netinet/in.h:60:9: this was the original definition
/usr/include/linux/in.h:31:9: warning: preprocessor token IPPROTO_ICMP
redefined
../include/sparse/netinet/in.h:63:9: this was the original definition
[...]
/usr/include/linux/in.h:28:3: error: bad enum definition
/usr/include/linux/in.h:28:3: error: Expected } at end of specifier
/usr/include/linux/in.h:28:3: error: got 0
/usr/include/linux/in.h:84:16: error: redefinition of struct in_addr

Signed-off-by: Daniele Di Proietto 
---
 include/sparse/netinet/in.h | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/include/sparse/netinet/in.h b/include/sparse/netinet/in.h
index 78e5981..8a5b887 100644
--- a/include/sparse/netinet/in.h
+++ b/include/sparse/netinet/in.h
@@ -18,8 +18,8 @@
 #error "Use this header only with sparse.  It is not a correct implementation."
 #endif
 
-#ifndef __NETINET_IN_SPARSE
-#define __NETINET_IN_SPARSE 1
+#ifndef _NETINET_IN_H
+#define _NETINET_IN_H 1
 
 #include "openvswitch/types.h"
 #include 
@@ -77,25 +77,25 @@ struct sockaddr_in6 {
 #define IPPORT_FTP 21
 
 /* All the IP options documented in Linux ip(7). */
-#define IP_ADD_MEMBERSHIP 0
-#define IP_DROP_MEMBERSHIP 1
-#define IP_HDRINCL 2
-#define IP_MTU 3
-#define IP_MTU_DISCOVER 4
-#define IP_MULTICAST_IF 5
-#define IP_MULTICAST_LOOP 6
-#define IP_MULTICAST_TTL 7
-#define IP_NODEFRAG 8
-#define IP_OPTIONS 9
-#define IP_PKTINFO 10
+#define IP_ADD_MEMBERSHIP 35
+#define IP_DROP_MEMBERSHIP 36
+#define IP_HDRINCL 3
+#define IP_MTU 14
+#define IP_MTU_DISCOVER 10
+#define IP_MULTICAST_IF 32
+#define IP_MULTICAST_LOOP 34
+#define IP_MULTICAST_TTL 33
+#define IP_NODEFRAG 22
+#define IP_OPTIONS 4
+#define IP_PKTINFO 8
 #define IP_RECVERR 11
-#define IP_RECVOPTS 12
+#define IP_RECVOPTS 6
 #define IP_RECVTOS 13
-#define IP_RECVTTL 14
-#define IP_RETOPTS 15
-#define IP_ROUTER_ALERT 16
-#define IP_TOS 17
-#define IP_TTL 18
+#define IP_RECVTTL 12
+#define IP_RETOPTS 7
+#define IP_ROUTER_ALERT 5
+#define IP_TOS 1
+#define IP_TTL 2
 
 #define INADDR_ANY  0x
 #define INADDR_BROADCAST0x
@@ -146,4 +146,4 @@ int inet_aton (const char *, struct in_addr *);
 const char *inet_ntop(int, const void *, char *, socklen_t);
 int inet_pton(int, const char *, void *);
 
-#endif /*  sparse */
+#endif /*  */
-- 
2.8.1

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

[ovs-dev] [PATCH] ofproto-dpif: Cache result of time_msec() for rule_expire().

[Daniele Di Proietto]

In the run() function of ofproto-dpif we call rule_expire() for every
possible flow that has a timeout and rule_expire() calls time_msec().
Calling time_msec() repeatedly can be pretty expensive, even though most
of the time it involves only a vdso call.

This commit calls time_msec only once in run(), to reduce the workload.

Keeping the flows ordered by expiration in some kind of heap or timing
wheel data structure could help make this process more efficient, if
rule_expire() turns out to be a bottleneck.

VMware-BZ: #1655122
Signed-off-by: Daniele Di Proietto 
---
 ofproto/ofproto-dpif.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index df4a632..91529fe 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -109,7 +109,7 @@ BUILD_ASSERT_DECL(offsetof(struct rule_dpif, up) == 0);
 static void rule_get_stats(struct rule *, uint64_t *packets, uint64_t *bytes,
long long int *used);
 static struct rule_dpif *rule_dpif_cast(const struct rule *);
-static void rule_expire(struct rule_dpif *);
+static void rule_expire(struct rule_dpif *, long long now);
 
 struct group_dpif {
 struct ofgroup up;
@@ -1545,6 +1545,7 @@ run(struct ofproto *ofproto_)
 new_dump_seq = seq_read(udpif_dump_seq(ofproto->backer->udpif));
 if (ofproto->dump_seq != new_dump_seq) {
 struct rule *rule, *next_rule;
+long long now = time_msec();
 
 /* We know stats are relatively fresh, so now is a good time to do some
  * periodic work. */
@@ -1555,7 +1556,7 @@ run(struct ofproto *ofproto_)
 ovs_mutex_lock(&ofproto_mutex);
 LIST_FOR_EACH_SAFE (rule, next_rule, expirable,
 &ofproto->up.expirable) {
-rule_expire(rule_dpif_cast(rule));
+rule_expire(rule_dpif_cast(rule), now);
 }
 ovs_mutex_unlock(&ofproto_mutex);
 
@@ -3621,11 +3622,10 @@ port_is_lacp_current(const struct ofport *ofport_)
 /* If 'rule' is an OpenFlow rule, that has expired according to OpenFlow rules,
  * then delete it entirely. */
 static void
-rule_expire(struct rule_dpif *rule)
+rule_expire(struct rule_dpif *rule, long long now)
 OVS_REQUIRES(ofproto_mutex)
 {
 uint16_t hard_timeout, idle_timeout;
-long long int now = time_msec();
 int reason = -1;
 
 hard_timeout = rule->up.hard_timeout;
-- 
2.8.1

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

Re: [ovs-dev] [PATCH V2 4/4] tests: Fix fail of OVS_APP_EXIT_AND_WAIT on Windows

[Joe Stringer]

On 1 June 2016 at 04:46, Paul Boca  wrote:
> The problem is that on some cases it gets called with the socket
> name instead of the service name.
>
> Signed-off-by: Paul-Daniel Boca 

Looking at commit 0c473314294930a47a18d380e0bbcdf7b02a16f2 which
introduced this macro, it seems like simply skipping these pieces
could cause some tests to intermittently fail, because "ovs-appctl ...
exit" does not wait until the process has terminated; it simply tells
the process to terminate itself, then returns.

What needs to happen differently on windows between validating that a
process has exited vs. a service has exited?

Is this something that we need to update the tests to, for example,
treat service exit differently from regular application exit?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH RFC v2 1/6] netdev-dpdk: Use instant sending instead of queueing of packets.

[Daniele Di Proietto]

I wanted to do this for a long time now, thanks for posting this patch.

I didn't notice a drop in throughput with this patch, for phy-ovs-phy
tests, even when we call rte_eth_tx_burst() for every single packet. 

How about 'dpdk_tx_burst()' instead of 'netdev_dpdk_eth_instant_send()'?
The "instant" part makes sense compared to the current code, but that
code is removed.

Acked-by: Daniele Di Proietto 

If there are no objection I can push this separately from the rest of
the series.

On 24/05/2016 06:34, "Ilya Maximets"  wrote:

>Current implementarion of TX packet's queueing is broken in several ways:
>
>   * TX queue flushing implemented on receive assumes that all
> core_id-s are sequential and starts from zero. This may lead
> to situation when packets will stuck in queue forever and,
> also, this influences on latency.
>
>   * For a long time flushing logic depends on uninitialized
> 'txq_needs_locking', because it usually calculated after
> 'netdev_dpdk_alloc_txq' but used inside of this function
> for initialization of 'flush_tx'.
>
>According to current flushing logic, constant flushing required if TX
>queues will be shared among different CPUs. Further patches will implement
>mechanisms for manipulations with TX queues in runtime. In this case PMD
>threads will not know is current queue shared or not. This means that
>constant flushing will be required.
>
>Conclusion: Lets remove queueing at all because it doesn't work
>properly now and, also, constant flushing required anyway.
>
>Testing on basic PHY-OVS-PHY and PHY-OVS-VM-OVS-PHY scenarios shows
>insignificant performance drop (less than 0.5 percents) in compare to
>profit that we can achieve in the future using XPS or other features.
>
>Signed-off-by: Ilya Maximets 
>---
> lib/netdev-dpdk.c | 102 --
> 1 file changed, 14 insertions(+), 88 deletions(-)
>
>diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>index 0d1b8c9..66e33df 100644
>--- a/lib/netdev-dpdk.c
>+++ b/lib/netdev-dpdk.c
>@@ -167,7 +167,6 @@ static const struct rte_eth_conf port_conf = {
> },
> };
> 
>-enum { MAX_TX_QUEUE_LEN = 384 };
> enum { DPDK_RING_SIZE = 256 };
> BUILD_ASSERT_DECL(IS_POW2(DPDK_RING_SIZE));
> enum { DRAIN_TSC = 20ULL };
>@@ -284,8 +283,7 @@ static struct ovs_list dpdk_mp_list 
>OVS_GUARDED_BY(dpdk_mutex)
> = OVS_LIST_INITIALIZER(&dpdk_mp_list);
> 
> /* This mutex must be used by non pmd threads when allocating or freeing
>- * mbufs through mempools. Since dpdk_queue_pkts() and dpdk_queue_flush() may
>- * use mempools, a non pmd thread should hold this mutex while calling them */
>+ * mbufs through mempools. */
> static struct ovs_mutex nonpmd_mempool_mutex = OVS_MUTEX_INITIALIZER;
> 
> struct dpdk_mp {
>@@ -299,17 +297,12 @@ struct dpdk_mp {
> /* There should be one 'struct dpdk_tx_queue' created for
>  * each cpu core. */
> struct dpdk_tx_queue {
>-bool flush_tx; /* Set to true to flush queue everytime */
>-   /* pkts are queued. */
>-int count;
> rte_spinlock_t tx_lock;/* Protects the members and the NIC queue
> * from concurrent access.  It is used only
> * if the queue is shared among different
> * pmd threads (see 'txq_needs_locking'). 
> */
> int map;   /* Mapping of configured vhost-user queues
> * to enabled by guest. */
>-uint64_t tsc;
>-struct rte_mbuf *burst_pkts[MAX_TX_QUEUE_LEN];
> };
> 
> /* dpdk has no way to remove dpdk ring ethernet devices
>@@ -703,19 +696,6 @@ netdev_dpdk_alloc_txq(struct netdev_dpdk *dev, unsigned 
>int n_txqs)
> 
> dev->tx_q = dpdk_rte_mzalloc(n_txqs * sizeof *dev->tx_q);
> for (i = 0; i < n_txqs; i++) {
>-int numa_id = ovs_numa_get_numa_id(i);
>-
>-if (!dev->txq_needs_locking) {
>-/* Each index is considered as a cpu core id, since there should
>- * be one tx queue for each cpu core.  If the corresponding core
>- * is not on the same numa node as 'dev', flags the
>- * 'flush_tx'. */
>-dev->tx_q[i].flush_tx = dev->socket_id == numa_id;
>-} else {
>-/* Queues are shared among CPUs. Always flush */
>-dev->tx_q[i].flush_tx = true;
>-}
>-
> /* Initialize map for vhost devices. */
> dev->tx_q[i].map = OVS_VHOST_QUEUE_MAP_UNKNOWN;
> rte_spinlock_init(&dev->tx_q[i].tx_lock);
>@@ -1056,16 +1036,15 @@ netdev_dpdk_rxq_dealloc(struct netdev_rxq *rxq)
> }
> 
> static inline void
>-dpdk_queue_flush__(struct netdev_dpdk *dev, int qid)
>+netdev_dpdk_eth_instant_send(struct netdev_dpdk *dev, int qid,
>+ struct rte_mbuf **pkts, int cnt)
> {
>-struct dpdk_tx_queue *txq = &dev->tx_q[qid];
> uint32_t nb_t

Re: [ovs-dev] [PATCH RFC v2 0/6] dpif-netdev: Manual pinning of RX queues + XPS.

[Daniele Di Proietto]

Hi Ilya,

apologies for the delay.

I didn't take a extremely detailed look at this series, but I have
a few high level comments.

Thanks for adding a command to configure the rxq affinity.  Have
you thought about using the database instead?  I think it will
be easier to use because it survives restarts, and one can batch
the affinity assignment for multiple ports without explicitly
calling pmd-reconfigure.  I'm not sure what the best interface
would look like. Perhaps a string in Interface:other_config that
maps rxqs with core ids?

I'd prefer to avoid exporting an explicit command like
dpif-netdev/pmd-reconfigure.  If we use the database we don't have to,
right?

I'm not sure what's the best way to introduce XPS in OVS.  First of all,
for physical NICs I'd want to keep the current model where possible
(one queue per core, no locking).  Maybe we can introduce some mapping
just for vhost-user ports in netdev-dpdk to implement packet steering?

Also, have you considered packet reordering issues?  If a 5-tuple is
processed by one core and we often change the tx queue, we end up
with the same 5-tuple on two different tx queues.

Lastly I'm not 100% sure we need a "n-txq" parameter.  I think that
for vhost-user ports, we know the value in new_device() (we should
do that for rxqs too now that we have netdev_reconfigure).  physical
NICs txqs should match the cpu cores and avoid locking, where
possible.

What do you think?

Thanks,

Daniele


On 24/05/2016 06:34, "Ilya Maximets"  wrote:

>Manual pinning of RX queues to PMD threads required for performance
>optimisation. This will give to user ability to achieve max. performance
>using less number of CPUs because currently only user may know which
>ports are heavy loaded and which are not.
>
>To give full controll on ports TX queue manipulation mechanisms also
>required. For example, to avoid issue described in 'dpif-netdev: XPS
>(Transmit Packet Steering) implementation.' which becomes worse with
>ability of manual pinning.
>( http://openvswitch.org/pipermail/dev/2016-March/067152.html )
>
>First 3 patches: prerequisites to XPS implementation.
>Patch #4: XPS implementation.
>Patches #5 and #6: Manual pinning implementation.
>
>Version 2:
>   * Rebased on current master.
>   * Fixed initialization of newly allocated memory in
> 'port_reconfigure()'.
>
>Ilya Maximets (6):
>  netdev-dpdk: Use instant sending instead of queueing of packets.
>  dpif-netdev: Allow configuration of number of tx queues.
>  netdev-dpdk: Mandatory locking of TX queues.
>  dpif-netdev: XPS (Transmit Packet Steering) implementation.
>  dpif-netdev: Add dpif-netdev/pmd-reconfigure appctl command.
>  dpif-netdev: Add dpif-netdev/pmd-rxq-set appctl command.
>
> INSTALL.DPDK.md|  44 +++--
> NEWS   |   4 +
> lib/dpif-netdev.c  | 393 ++---
> lib/netdev-bsd.c   |   1 -
> lib/netdev-dpdk.c  | 198 ++-
> lib/netdev-dummy.c |   1 -
> lib/netdev-linux.c |   1 -
> lib/netdev-provider.h  |  18 +--
> lib/netdev-vport.c |   1 -
> lib/netdev.c   |  30 
> lib/netdev.h   |   1 -
> vswitchd/ovs-vswitchd.8.in |  10 ++
> 12 files changed, 400 insertions(+), 302 deletions(-)
>
>-- 
>2.5.0
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] netdev-dpdk: Fix PMD threads hang in __netdev_dpdk_vhost_send().

[Daniele Di Proietto]

On 25/05/2016 04:03, "Ilya Maximets"  wrote:

>On 23.05.2016 17:55, Traynor, Kevin wrote:
>>> -Original Message-
>>> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
>>> Sent: Tuesday, May 17, 2016 4:09 PM
>>> To: dev@openvswitch.org; Daniele Di Proietto 
>>> Cc: Dyasly Sergey ; Heetae Ahn
>>> ; Flavio Leitner ;
>>> Traynor, Kevin ; Pravin B Shelar
>>> ; Ilya Maximets 
>>> Subject: [PATCH] netdev-dpdk: Fix PMD threads hang in
>>> __netdev_dpdk_vhost_send().
>>>
>>> There are situations when PMD thread can hang forever inside
>>> __netdev_dpdk_vhost_send() because of broken virtqueue ring.
>>>
>>> This happens if rte_vring_available_entries() always positive and
>>> rte_vhost_enqueue_burst() can't send anything (possible with broken
>>> ring).
>>>
>>> In this case time expiration will be never checked and 'do {} while
>>> (cnt)'
>>> loop will be infinite.
>>>
>>> This scenario sometimes reproducible with dpdk-16.04-rc2 inside guest
>>> VM.
>>> Also it may be reproduced by manual braking of ring structure inside
>>> the guest VM.
>>>
>>> Fix that by checking time expiration even if we have available
>>> entries.
>> 
>> Hi Ilya,
>
>Hi, Kevin.
>
>Christian and Thiago CC-ed, because, I think, they're faced with similar issue.
>
>> 
>> Thanks for catching this. This intersects with something else I've seen
>> wrt retry code and there's a few options...
>> 
>> 1. Remove retries when nothing sent. For the VM that needs retries it is a
>> good thing to have, but Bhanu and I saw in a test with multiple VM's recently
>> that if one VM causes a lot of retries there is a large performance 
>> degradation
>> for the other VM's. So I changed the retry to only occur when at least one 
>> packet
>> has been sent on the previous call. I put a patch up here.
>> http://openvswitch.org/pipermail/dev/2016-May/071517.html
>> 
>> If we keep retries we can either
>> 
>> 2. Make more robust coordination between rte_ring_available_entries() and
>> rte_vhost_enqueue_burst(), as per your patch.
>> 
>> 3. As you've shown that we can't rely on the rte_ring_available_entries() to 
>> know we
>> can enqueue, how about just remove it and use rte_vhost_enqueue_burst() 
>> directly
>> in the retry loop.
>> 
>> My preference would be for 1. because on balance I'd rather one VM did not 
>> degrade
>> performance of others, more than I'd like it to have retries. Of course 
>> there could
>> be some compromise between them as well i.e. reduce amount of retries, but 
>> any retries
>> could affect performance for another path if they are using the same core.
>> 
>> What do you think?
>
>I'm worry about scenarios with "pulsing" traffic, i.e. if we have not very big 
>but
>enough amount of packets to overload vring in a short time and long period of 
>silence
>after that. HW can keep in its RX queues much more packets than can be pushed 
>to
>virtio ring. In this scenario, without retrying, most of packets will be 
>dropped.
>
>How about just decreasing of VHOST_ENQ_RETRY_USECS to, may be, 1 usec with my 
>fix
>applied of course? Such interval should be enough to handle 20G traffic with 
>64B
>packets by one PMD thread. And, also, this timeout may be applied to both cases
>(something sent or not) to decrease cost of retrying.
>
>Best regards, Ilya Maximets.

I haven't done any performance testing with many vms, but ...

I think the retry logic was introduced because at the time NETDEV_MAX_BURST
was 192 and we felt that batches of 192 packets could easily overload the
guest ring.

Now that NETDEV_MAX_BURST is only 32, I agree with Kevin on applying solution 1.
Retries can degrade performance for other vms, which IMHO is worse than
dropping packets destined for a "slow" receiver vm.

Thanks,

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

Re: [ovs-dev] [PATCH] netdev-dpdk: NUMA Aware vHost User

[Daniele Di Proietto]

Thanks for the patch!

I'm not sure how to best handle the libnuma dependency. Question:
Is it still useful to move the device to a PMD thread on the appropriate
numa socket, even if DPDK is compiled without
CONFIG_RTE_LIBRTE_VHOST_NUMA? If it's useful, I'm fine with the
approach followed by this patch.  Otherwise I think we should handle
the -lnuma inclusion like -lfuse for CUSE and introduce two ifdefs (one
on #include  and one on new_device()).

Small comments inline, otherwise this looks good to me.

Thanks,

Daniele

2016-05-24 6:15 GMT-07:00 Ciara Loftus :

> This commit allows for vHost User memory from QEMU, DPDK and OVS, as
> well as the servicing PMD, to all come from the same socket.
>
> The socket id of a vhost-user port used to be set to that of the master
> lcore. Now it is possible to update the socket id if it is detected
> (during VM boot) that the vhost device memory is not on this node. If
> this is the case, a new mempool is created from the new node, and the
> PMD thread currently servicing the port will no longer, in favour of a
> thread from the new node (if enabled in the pmd-cpu-mask).
>
> To avail of this functionality, one must enable the
> CONFIG_RTE_LIBRTE_VHOST_NUMA DPDK configuration option.
>
> Signed-off-by: Ciara Loftus 
> ---
>  .travis.yml |  3 +++
>  INSTALL.DPDK.md |  8 ++--
>  NEWS|  3 +++
>  acinclude.m4|  2 +-
>  lib/netdev-dpdk.c   | 37 ++---
>  rhel/openvswitch-fedora.spec.in |  1 +
>  6 files changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index ee2cf21..faba325 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -11,10 +11,13 @@ addons:
>  packages:
>- bc
>- gcc-multilib
> +  - libnuma1
>

I think libnuma-dev depends on libnuma1, so the above line might not be
necessary.


> +  - libnuma-dev
>- libssl-dev
>- llvm-dev
>- libjemalloc1
>- libjemalloc-dev
> +  - numactl
>

Do we need the numactl package?


>
>  before_install: ./.travis/${TRAVIS_OS_NAME}-prepare.sh
>
> diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
> index 93f92e4..bbe0234 100644
> --- a/INSTALL.DPDK.md
> +++ b/INSTALL.DPDK.md
> @@ -16,7 +16,7 @@ OVS needs a system with 1GB hugepages support.
>  Building and Installing:
>  
>
> -Required: DPDK 16.04
> +Required: DPDK 16.04, libnuma
>  Optional (if building with vhost-cuse): `fuse`, `fuse-devel`
> (`libfuse-dev`
>  on Debian/Ubuntu)
>
> @@ -443,7 +443,11 @@ Performance Tuning:
>
> It is good practice to ensure that threads that are in the
> datapath are
> pinned to cores in the same NUMA area. e.g. pmd threads and QEMU
> vCPUs
> -   responsible for forwarding.
> +   responsible for forwarding. If DPDK is built with
> +   CONFIG_RTE_LIBRTE_VHOST_NUMA=y, vHost User ports automatically
> +   detect the NUMA socket of the QEMU vCPUs and will be serviced by a
> PMD
> +   from the same node provided a core on this node is enabled in the
> +   pmd-cpu-mask.
>
>9. Rx Mergeable buffers
>
> diff --git a/NEWS b/NEWS
> index 4e81cad..24ca39f 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -32,6 +32,9 @@ Post-v2.5.0
>   * DB entries have been added for many of the DPDK EAL command line
> arguments. Additional arguments can be passed via the dpdk-extra
> entry.
> + * PMD threads servicing vHost User ports can now come from the NUMA
> +   node that device memory is located on if
> CONFIG_RTE_LIBRTE_VHOST_NUMA
> +   is enabled in DPDK.
> - ovs-benchmark: This utility has been removed due to lack of use and
>   bitrot.
> - ovs-appctl:
> diff --git a/acinclude.m4 b/acinclude.m4
> index f3de855..99ddf04 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -218,7 +218,7 @@ AC_DEFUN([OVS_CHECK_DPDK], [
>  DPDKLIB_FOUND=false
>  save_LIBS=$LIBS
>  for extras in "" "-ldl"; do
> -LIBS="$DPDK_LIB $extras $save_LIBS $DPDK_EXTRA_LIB"
> +LIBS="$DPDK_LIB $extras $save_LIBS $DPDK_EXTRA_LIB -lnuma"
>  AC_LINK_IFELSE(
> [AC_LANG_PROGRAM([#include 
>   #include ],
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index 0d1b8c9..ad6c4bb 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "dirs.h"
>  #include "dp-packet.h"
> @@ -378,6 +379,9 @@ struct netdev_dpdk {
>   * netdev_dpdk*_reconfigure() is called */
>  int requested_n_txq;
>  int requested_n_rxq;
> +
> +/* Socket ID detected when vHost device is brought up */
> +int requested_socket_id;
>  };
>
>  struct netdev_rxq_dpdk {
> @@ -747,6 +751,7 @@ netdev_dpdk_init(struct netdev *netdev, unsigned int
> port_no,
>  }
>
>  dev->socket_id = sid < 0 ? SOCKET0 : sid;
> +dev->requested_socket_id = dev

Re: [ovs-dev] [PATCH 3/4] datapath-windows: STT reassemble small fix

[Sairam Venugopal]

Thanks for fixing this. Should we log an error if we try to copy more than
allocated packet length?

Acked-by: Sairam Venugopal 


On 5/17/16, 8:23 AM, "Paul Boca"  wrote:

>Fixed possible deadlock in case NdisGetDataBuffer fails
>Validate the segment length and offset on reassemble to avoid buffer
>overflow
>
>Signed-off-by: Paul-Daniel Boca 
>---
> datapath-windows/ovsext/Stt.c | 16 +---
> datapath-windows/ovsext/Stt.h |  1 +
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Stt.c b/datapath-windows/ovsext/Stt.c
>index 5b5d950..8a1b1a9 100644
>--- a/datapath-windows/ovsext/Stt.c
>+++ b/datapath-windows/ovsext/Stt.c
>@@ -607,9 +607,6 @@ OvsSttReassemble(POVS_SWITCH_CONTEXT switchContext,
> SttHdr *sttHdr = NULL;
> sourceNb = NET_BUFFER_LIST_FIRST_NB(curNbl);
> 
>-/* XXX optimize this lock */
>-NdisAcquireSpinLock(&OvsSttSpinLock);
>-
> /* If this is the first fragment, copy the STT header */
> if (segOffset == 0) {
> sttHdr = NdisGetDataBuffer(sourceNb, sizeof(SttHdr), &stt, 1, 0);
>@@ -621,6 +618,14 @@ OvsSttReassemble(POVS_SWITCH_CONTEXT switchContext,
> startOffset = startOffset + STT_HDR_LEN;
> }
> 
>+if (offset + fragmentLength > innerPacketLen) {
>+// avoid buffer overflow on copy
>+return NULL;
>+}
>+
>+/* XXX optimize this lock */
>+NdisAcquireSpinLock(&OvsSttSpinLock);
>+
> /* Lookup fragment */
> OVS_STT_PKT_KEY pktKey = OvsGeneratePacketKey(ipHdr, tcp);
> UINT32 hash = OvsSttGetPktHash(&pktKey);
>@@ -649,6 +654,7 @@ OvsSttReassemble(POVS_SWITCH_CONTEXT switchContext,
> }
> 
> /* Copy the data from Source to new buffer */
>+entry->allocatedLen = innerPacketLen;
> entry->packetBuf = OvsAllocateMemoryWithTag(innerPacketLen,
> OVS_STT_POOL_TAG);
> if (OvsGetPacketBytes(curNbl, fragmentLength, startOffset,
>@@ -661,6 +667,10 @@ OvsSttReassemble(POVS_SWITCH_CONTEXT switchContext,
> InsertHeadList(&OvsSttPktFragHash[hash & STT_HASH_TABLE_MASK],
>&entry->link);
> } else {
>+if (offset + fragmentLength > pktFragEntry->allocatedLen) {
>+// don't copy more than it is allocated
>+goto handle_error;
>+}
> /* Add to recieved length to identify if this is the last
>fragment */
> pktFragEntry->recvdLen += fragmentLength;
> lastPacket = (pktFragEntry->recvdLen == innerPacketLen);
>diff --git a/datapath-windows/ovsext/Stt.h b/datapath-windows/ovsext/Stt.h
>index 20066e6..8aea164 100644
>--- a/datapath-windows/ovsext/Stt.h
>+++ b/datapath-windows/ovsext/Stt.h
>@@ -67,6 +67,7 @@ typedef struct _OVS_STT_PKT_ENTRY {
> OVS_STT_PKT_KEY ovsPktKey;
> UINT64  timeout;
> UINT32  recvdLen;
>+UINT32  allocatedLen;
> SttHdr  sttHdr;
> PCHAR   packetBuf;
> LIST_ENTRY  link;
>-- 
>2.7.2.windows.1
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev&d=CwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Dc
>ruz40PROJ40ROzSpxyQSLw6fcrOWpJgEcEmNR3JEQ&m=ks6H7c0dJA42Wc_Cm_8KRvAlNMZCZ1
>q0OcbL35AInvU&s=rCUHnvtDWaBmIb-8bKkBv6GpeDHX48S_WwQUS2yXLuc&e= 

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

[ovs-dev] [PATCH v2] ovn-northd.8.xml: fix sock path of NB and SB database.

[Li Wei]

commit 60bdd01148e4 ("Separating OVN NB and SB database processes")
introduced a separating OVN NB and SB database process, the path of
sock files need to be updated.

Fixes: 60bdd01148e4 ("Separating OVN NB and SB database processes")
Signed-off-by: Li Wei 
---
v1 -> v2:
* fix typo(thanks Aaron Conole)
* cc RYAN D. MOATS
---
 ovn/northd/ovn-northd.8.xml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index 970c352..4603db8 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -21,7 +21,8 @@
 Configuration
 
   ovn-northd requires a connection to the Northbound
-  and Southbound databases.  The default is db.sock
+  and Southbound databases.  The defaults are ovnnb_db.sock
+  and ovnsb_db.sock respectively
   in the local Open vSwitch's "run" directory.  This may be
   overridden with the following commands:
 
-- 
2.4.11


___
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 1/4] datapath-windows: Improved offloading on STT tunnel

[Sairam Venugopal]

Hi Paul,

Thanks for updating the patch. I had some minor comments that I have added
inline.

It looks good overall.

Thanks,
Sairam

On 5/17/16, 8:23 AM, "Paul Boca"  wrote:

>*Added OvsExtractLayers - populates only the layers field without
>unnecessary
>memory operations for flow part
>*If in STT header the flags are 0 then force packets checksums calculation
>on receive.
>*Ensure correct pseudo checksum is set for LSO both on send and receive.
>Linux includes the segment length to TCP pseudo-checksum conforming to
>RFC 793 but in case of LSO Windows expects this to be only on
>Source IP Address, Destination IP Address, and Protocol.
>*Fragment expiration on rx side of STT was set to 30 seconds, but the
>correct
>timeout would be TTL of the packet
>
>Signed-off-by: Paul-Daniel Boca 
>---
>v2: Fixed a NULL pointer dereference.
>  Removed some unused local variables and multiple initializations.
>v3: Use LSO V2 in OvsDoEncapStt
>  Fixed alignment and code style
>  Use IpHdr TTL for fragment expiration on receive instead 30s
>V4: Use stored MSS in STT header on rx for lsoInfo of encapsulated packet
>  If STT_CSUM_VERIFIED flag is set then we don't have to extract
>  layers on receive.
>V5: If CSUM_VERIFIED or no flag is set in STT header then don't recompute
>  checksums
>V6: Add define for conversion of TTL to seconds
>  Fixes LSO MSS on rx side
>  Compute TCP checksum only once on TX side over STT header
>---
> datapath-windows/ovsext/Flow.c | 243
>-
> datapath-windows/ovsext/Flow.h |   2 +
> datapath-windows/ovsext/IpHelper.h |   3 +-
> datapath-windows/ovsext/PacketParser.c |  97 +++--
> datapath-windows/ovsext/PacketParser.h |   8 +-
> datapath-windows/ovsext/Stt.c  | 127 +
> datapath-windows/ovsext/Stt.h  |   1 -
> datapath-windows/ovsext/User.c |  17 ++-
> 8 files changed, 381 insertions(+), 117 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Flow.c
>b/datapath-windows/ovsext/Flow.c
>index d957d39..3af1da5 100644
>--- a/datapath-windows/ovsext/Flow.c
>+++ b/datapath-windows/ovsext/Flow.c
>@@ -1570,7 +1570,8 @@ _MapKeyAttrToFlowPut(PNL_ATTR *keyAttrs,
> 
> ndKey = NlAttrGet(keyAttrs[OVS_KEY_ATTR_ND]);
> RtlCopyMemory(&icmp6FlowPutKey->ndTarget,
>-  ndKey->nd_target, sizeof
>(icmp6FlowPutKey->ndTarget));
>+  ndKey->nd_target,
>+  sizeof (icmp6FlowPutKey->ndTarget));
> RtlCopyMemory(icmp6FlowPutKey->arpSha,
>   ndKey->nd_sll, ETH_ADDR_LEN);
> RtlCopyMemory(icmp6FlowPutKey->arpTha,
>@@ -1600,8 +1601,10 @@ _MapKeyAttrToFlowPut(PNL_ATTR *keyAttrs,
> arpFlowPutKey->nwSrc = arpKey->arp_sip;
> arpFlowPutKey->nwDst = arpKey->arp_tip;
> 
>-RtlCopyMemory(arpFlowPutKey->arpSha, arpKey->arp_sha,
>ETH_ADDR_LEN);
>-RtlCopyMemory(arpFlowPutKey->arpTha, arpKey->arp_tha,
>ETH_ADDR_LEN);
>+RtlCopyMemory(arpFlowPutKey->arpSha, arpKey->arp_sha,
>+  ETH_ADDR_LEN);
>+RtlCopyMemory(arpFlowPutKey->arpTha, arpKey->arp_tha,
>+  ETH_ADDR_LEN);
> /* Kernel datapath assumes 'arpFlowPutKey->nwProto' to be in
>host
>  * order. */
> arpFlowPutKey->nwProto = (UINT8)ntohs((arpKey->arp_op));
>@@ -1850,29 +1853,195 @@ OvsGetFlowMetadata(OvsFlowKey *key,
> return status;
> }
> 
>+
> /*
>- 
>*-
>---
>- * Initializes 'flow' members from 'packet', 'skb_priority', 'tun_id',
>and
>- * 'ofp_in_port'.
>- *
>- * Initializes 'packet' header pointers as follows:
>- *
>- *- packet->l2 to the start of the Ethernet header.
>- *
>- *- packet->l3 to just past the Ethernet header, or just past the
>- *  vlan_header if one is present, to the first byte of the payload
>of the
>- *  Ethernet frame.
>- *
>- *- packet->l4 to just past the IPv4 header, if one is present and
>has a
>- *  correct length, and otherwise NULL.
>- *
>- *- packet->l7 to just past the TCP, UDP, SCTP or ICMP header, if
>one is
>- *  present and has a correct length, and otherwise NULL.
>- *
>- * Returns NDIS_STATUS_SUCCESS normally.  Fails only if packet data
>cannot be accessed
>- * (e.g. if Pkt_CopyBytesOut() returns an error).
>- 
>*-
>---
>- */
>+*
>
>+* Initializes 'layers' members from 'packet'
>+*
>+* Initializes 'layers' header pointers as follows:
>+*
>+*- layers->l2 to the start of the Ethernet header.
>+*
>+*- layers->l3 to just past the Ethernet header, or just past the
>+*  vlan_header if one is present, to the first 

Re: [ovs-dev] [PATCH] ovn-northd.8.xml: fix sock path of NB and SB database.

[Li Wei]

Hi,

On 05/31/2016 10:59 PM, Aaron Conole wrote:
> Li Wei  writes:
> 
>> commit 60bdd01 ("Separating OVN NB and SB database processes") introduced
>> a separating OVN NB and SB database process, the path of sock file need
>> to be updated.
>>
>> Fixes: 60bdd01 ("Separating OVN NB and SB database processes")
>> Signed-off-by: Li Wei 
>> ---
>>  ovn/northd/ovn-northd.8.xml | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
>> index 970c352..4603db8 100644
>> --- a/ovn/northd/ovn-northd.8.xml
>> +++ b/ovn/northd/ovn-northd.8.xml
>> @@ -21,7 +21,8 @@
>>  Configuration
>>  
>>ovn-northd requires a connection to the Northbound
>> -  and Southbound databases.  The default is db.sock
>> +  and Southbound databases.  The default are ovnnb_db.sock
> 
> Just a nit, but since you're editing anyway, I think this should read:
> "The defaults are" instead of "The default are"

Thanks for pointing out this, I'll post a v2.

> 
>> +  and ovnsb_db.sock respectively
>>in the local Open vSwitch's "run" directory.  This may be
>>overridden with the following commands:
>>  
> 
> Thanks,
> -Aaron
> 
> 
> 


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

Re: [ovs-dev] [PATCH monitor_cond V6 05/11] ovsdb-client: support monitor-cond method

[Ben Pfaff]

On Tue, May 17, 2016 at 05:27:03PM +0300, Liran Schour wrote:
> Add monitor_cond method to ovsdb-client. Add unit tests.
> See ovsdb-client(1) man page for details.
> Replace monitor2 with monitor_cond.
> 
> Signed-off-by: Liran Schour 

Thanks for the updated patch.

In the documentation, s/emtpy/empty/, s/mointor/monitor/.

Please write some tests for update_cond_update (possibly add a unixctl
command for ovsdb-client to update the conditions?).

There are some references in comments to OVS before 2.5 not supporting
monitor_cond.  I think that these should be updated to 2.6?

Thanks,

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

Re: [ovs-dev] [PATCH monitor_cond V6 04/11] ovsdb: generate update notifications for monitor_cond session

[Ben Pfaff]

On Tue, May 17, 2016 at 05:27:02PM +0300, Liran Schour wrote:
> Hold session's conditions in ovsdb_monitor_session_condition. Pass it
> to ovsdb_monitor for generating "update2" notifications.
> Add functions that can generate "update2" notification for a
> "monitor_cond" session.
> JSON cache is enabled only for session's with true condition only.
> "monitor_cond" and "monitor_cond_change" are RFC 7047 extensions
> described by ovsdb-server(1) manpage.

Thanks for the updated patch.

Please make ovsdb_monitor_session_condition_destroy() accept a null
pointer argument and treat it as a no-op, and then remove the check from
the caller, following CodingStyle:

Functions that destroy an instance of a dynamically-allocated type
should accept and ignore a null pointer argument.  Code that calls
such a function (including the C standard library function free())
should omit a null-pointer check.  We find that this usually makes
code easier to read.

In the documentation, s/Replay/Reply/, s/deescribed/described/,
s/origin/original/.

In the documentation, there's a reference to [*] but that I
think that should be [*] (without the 's').  The updated
meaning of  is described in a couple of places, but I think
that instead we should just describe an update to the definition of
, for whatever section defines  (and probably
should do that for the commit a few patches ago that actually updates
the condition parser).

There's a stray comma on a line by itself in the documentation, here:

+contains the contents of the tables for which "initial" rows are selected.
+If no tables initial contents are requested, then "result" is an empty 
object.
+,
+.IP

The parentheticals look funny in the documentation here, I'd suggest
just removing them:

+.IP \(bu
+If "insert" is omitted or true, "update" notifications are sent for rows 
newly
+inserted into the table that match conditions or for rows modified in the 
table
+so that their old version does not match the condition and new version 
does.
+(new row in the client's replica table)
+.IP \(bu
+If "delete" is omitted or true, "update" notifications are sent for rows 
deleted
+from the table that match conditions or for rows modified in the table so 
that
+their old version does match the conditions and new version does not. 
(deleted row
+in the client's replica)

In the documentation for monitor_cond_update, I'm not sure there's value
in describing what's currently unsupported.

We already have some messages with "update" in their names with quite
different semantics.  What if we renamed monitor_cond_update to
monitor_cond_change or similar?  Then there would be less confusion.

I don't understand the design for how the monitor_cond_update replies
are meant to be handled.  The client's goal is probably to know how the
database content as seen through the new condition differs from the
database content as seen through the old condition; let's call this
difference D, just to be clear.  The documentation says such an update
is only sent after the monitor_cond_update reply:

Updates as a result of a condition change, will be sent only after
the client received a response to the "monitor_cond_update" request.

With that design, I don't see how the client can find out whether D is
empty or nonempty without waiting for an indefinite time or for some
further change to occur.  For example, if D is empty and the database
does not change, then the client will wait forever to receive a new
update2 notification.  The client can't simply assume that D is empty;
after all, what if the database is just slow?  To solve the problem, I
would suggest that we change the design, so that the documentation would
be more like:

An update, if any, as a result of a condition change, will be sent
to the client before the reply to the "monitor_cond_update" request.

Thanks,

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

[ovs-dev] Tscvtrc q

[Mail Delivery Subsystem]

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

Re: [ovs-dev] [PATCH monitor_cond V6 03/11] ovsdb: allow unmonitored columns in condition evaluation

[Ben Pfaff]

On Tue, May 17, 2016 at 05:27:01PM +0300, Liran Schour wrote:
> This commit allows to add unmonitored columns to a monitored table
> due to condition update.
> It will be used to evaluate conditions on unmonitored columns.
> Update notification includes only monitored columns.
> Due to the limited number of columns, we do not remove unused unmonitored
> columns on condition update for code simplicity.
> 
> Signed-off-by: Liran Schour 

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

Re: [ovs-dev] [PATCH] acinclude: fix issue when configuring with --with-dpdk

[Ben Pfaff]

On Wed, Jun 01, 2016 at 08:31:26PM +0200, Mauricio Vásquez wrote:
> Hi Ben,
> 
> On Wed, Jun 1, 2016 at 7:38 PM, Ben Pfaff  wrote:
> 
> > On Wed, Jun 01, 2016 at 06:48:07PM +0200, Mauricio Vasquez B wrote:
> > > when an empty path is given to the --with-dpdk option
> > > (--with-dpdk="" or --width-dpdk=$NON_SET_ENV_VARIABLE) the configure
> > > script does not show any error and configures OvS without DPDK support,
> > > this can create some confusion.
> > >
> > > This patch modifies that behavior showing an explicity error in that
> > case.
> > >
> > > Signed-off-by: Mauricio Vasquez B <
> > mauricio.vasquezber...@studenti.polito.it>
> >
> > Doesn't apply, please send a patch against current master.
> >
> I'm lost, you already applied it to master. Was this email for somebody
> else?

I think that this is a revised version of the patch I applied.  If so,
please send it as a patch against current master.  If not, there is
nothing to do.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2 0/2] vhost-user: Add the ability to control ownership/permissions

[Aaron Conole]

Ansis Atteka  writes:

> On 20 May 2016 at 13:32, Aaron Conole  wrote:
>
>> Currently, when using Open vSwitch with DPDK and qemu guests, the
>> recommended
>> method for joining the guests is via the dpdkvhostuser interface. This
>> interface uses Unix Domain sockets to communicate. When these sockets are
>> created, they inherit the permissions and ownership from the vswitchd
>> process.
>> This can lead to an undesirable state where the QEMU process cannot use the
>> socket file until manual intervention is performed (via `chown` and/or
>> `chmod`
>> calls).
>>
>
> Hi Aaron,
>
> Could you explain:
> 1. who would be setting the owner via this newly introduced OVSDB interface?

I always viewed this as a feature of convenience in the following case:

1. Start Open vSwitch
2. Start DPDK
3. Run qemu (as a non-root user)
3a. Observe failure (permission denied)
4. Okay, darn - ch*() files
5. Re-run qemu
5a. Observe success

As a user, I am not very smart.  I don't see a way to set things
like umasks, directory group bits, or anything else.  And I don't see
any such knobs in Open vSwitch today.

If your question is for a specific user I have in mind, I don't have
one.  I'm thinking about the general case.  What is the most _useful_
thing to provide.  I think a combination of MAC and DAC approaches make
sense, but as I said in the previous paragraph - "I am not very smart."
:-)

> 2. who would be starting the QEMU process for use-cases you are trying to
> solve here?
>
> I am asking this because in another thread [
> http://openvswitch.org/pipermail/dev/2016-June/071935.html] I had
> discussion with Libvirt folks and they explained to me that under their
> current security model they think it should be Libvirt doing the actual
> chown() calls and that they would prefer not use Open vSwitch as a proxy to
> do it for them. This is at least what they apparently have been doing all
> this time to lock down privileges for QEMU processes.

That's great.  That means libvirt may actually do something to make this
easier.  However, what about the _next_ hypervisor that comes along?  Or
the next vhost-user based back-end?  Those still require some kind of
solution, and having the ability to at least fall back on DAC is quite
handy.  It feels more complete.

> Some food for thoughts:
> 1. What, if in future Libvirt will chown() the DPDK sockets directly and
> override the value set in OVSDB (assuming QEMU is started by libvirt, but
> ovs-vsctl is invoked by some other process)?

That's fine.  It's no different than today (just imagine that libvirt is
fixed to calling chown and chmod, without changing from the current
user/group and umask values).

> 2. What about Mandatory Access Control security context (the one you see in
> `ls -Z ` output on RHEL-type distributions)? Do you plan to set it as
> well in the future from ovs-vswitchd? MAC is another security layer that
> Libvirt uses to confine QEMU.

I think it should be used as well.  I don't think these are competing
technologies, or a case where we need to provide one vs. another.  I
view them as complementary, and we have the opportunity to provide
both.  That way, at least on systems where users decide that `setenforce
Permissive` is a fine thing to do, there's something that does provide
some semblance of control.  The way it stands now is confusing.

> 3. Also this patch kinda conflicts with --user flag because then ovs user
> would have to be put under "qemu" group to be able to chown sockets to
> "qemu" user. This reexposes OVS to untrusted resources owned by qemu user.
> Anyway this flag does not work with DPDK anyway and I think we may want to
> deprecate it.

For now, I am going to leave this alone.  DPDK requires root access at
the moment, so it's only vaguely relevant.

> Also what you have may be completely fine:
> 1. as a short term solution for Libvirt if it currently does not chown()
> DPDK sockets; OR

I agree, this does provide a solution in that case as well.  I'm not
currently working on libvirt for this.

> 2. if you are targeting this feature for hypervisors that are not using
> Libvirt and have completely different security model.

I think it needs to be considered.  OvS isn't part of libvirt, so the
features provided should really be considerate of other deployments, as
well.

Hopefully I don't sound too naive, and I've made a case why this feature
is good to have.

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

Re: [ovs-dev] [PATCH monitor_cond V6 02/11] ovsdb: add conditions utilities to support monitor_cond

[Ben Pfaff]

On Tue, May 17, 2016 at 05:27:00PM +0300, Liran Schour wrote:
> Change ovsdb_condition to be a 3-element json array or a boolean value.
> Conditions utilities will be used later for conditional monitoring.
> 
> Signed-off-by: Liran Schour 

I believe that this actually extends the OVSDB protocol.  When we make
extensions, we document them in ovsdb/ovsdb-server.1.in, in the section
titled SPECIFICATIONS, so please add a description there.

The code in ovsdb_clause_from_json() for converting JSON_TRUE into
OVSDB_F_TRUE and JSON_FALSE into OVSDB_F_FALSE seems awfully indirect.
Why not just use the enums directly?
+if (json->type == JSON_TRUE || json->type == JSON_FALSE) {
+function_name = (json->type == JSON_TRUE) ? "true" : "false";
+error = ovsdb_function_from_string(function_name, &clause->function);

Please use capital letters and punctuation in comments:
+/* column and arg fields are not being used with boolean function
+ * use dummy values */

It should not be possible to hit these cases in
ovsdb_clause_from_json(), so please use OVS_NOT_REACHED():
+case OVSDB_F_TRUE:
+case OVSDB_F_FALSE:

There are a couple of instances of
 ? true : false
in this patch.  Please just drop the ?: part, it's a no-op, e.g.
+return json_boolean_create(clause->function == OVSDB_F_TRUE ?
+   true : false);
becomes
+return json_boolean_create(clause->function == OVSDB_F_TRUE);

Thanks,

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

Re: [ovs-dev] [PATCH v3 00/16] Userspace (DPDK) connection tracker

[Daniele Di Proietto]

Hi Antonio,

I did some very simple benchmarks of the connection tracker
between two phy ports (OpenFlow port 1 and 2).

This is the flow table: it doesn't stress classification,
but it includes one recirculation:

ct_state=-trk,actions=ct(commit,table=0)
in_port=1,ct_state=+trk,actions=2


With 64-bytes UDP packets:

n_connections | throughput(Mpps)
2 | 5.01
   10 | 4.76
  100 | 4.07
 1000 | 2.82
1 | 1.83
   10 | 1.44
  100 | 1.13
  300 | 1.11

I think most of the drop between 100 and 1000 is due to EMC misses.

I also did some TCP testing with netperf TCP_STREAM, but I didn't notice
any difference if I removed the ct action from the pipeline, so the
connection tracker is not the bottleneck (we can easily move 10Gbps of
TCP 1500 bytes traffic, but that's not a significant result).

Thanks,

Daniele

On 26/05/2016 02:45, "Fischetti, Antonio"  wrote:

>Hi Daniele,
>do you have any performance figures related to this implementation?
>I know that performance may change quite a lot depending on the type 
>of traffic data.
>
>Thanks,
>Antonio
>
>> -Original Message-
>> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Daniele
>> Di Proietto
>> Sent: Tuesday, May 17, 2016 1:56 AM
>> To: dev@openvswitch.org
>> Subject: [ovs-dev] [PATCH v3 00/16] Userspace (DPDK) connection
>> tracker
>> 
>> This series aims to implement the ct() action for the dpif-netdev
>> datapath.
>> The bulk of the code is in the new conntrack module: it contains some
>> packet
>> parsing code, some lookup tables and the logic to implements all the
>> ct bits.
>> 
>> The conntrack module is helped by conntrack-tcp, for TCP window and
>> flags
>> tracking: the bulk of the code of this submodule is from the
>> FreeBSD's pf
>> subsystem, therefore is BSD licensed.
>> 
>> The rest of the series integrates the connection tracker with the
>> rest of
>> OVS: the ct() action is implemented in dpif-netdev, and the debugging
>> interfaces required by dpctl/{dump,flush}-conntrack are implemented.
>> 
>> Besides adding some unit tests, this series ports the existing
>> conntrack
>> system test to the userspace datapath.  Some small modifications are
>> required to pass the testsuite, and some tests still have to be
>> skipped.
>> 
>> This can also be downloaded at:
>> 
>> https://github.com/ddiproietto/ovs/tree/userconntrack_20160516
>> 
>> Any feedback is appreciated, thanks.
>> 
>> v2 -> v3:
>> * Rebased.
>> * Squashed commits for flushing (in dpif-netdev and conntrack).
>> * Squashed commits for dumping (in dpif-netdev and conntrack).
>> * Use adaptive mutex instead of spinlock: this prevents livelock
>>   if the cleanup thread is executed on the same CPU as a forwarding
>>   thread.  Performance impact in minimal.
>> * Validate L3 and L4 checksum.
>> * Use proper L3 and L4 checksum in hardcoded packets in system and
>> unit
>>   tests.
>> * Consider ICMPv6 as well as ICMP in l4_protos and conn_key_to_tuple.
>> * Mention conntrack in NEWS and FAQ.md.
>> * Use uint16_t for ct_state.
>> * Fix possible NULL dereference for conn in process_one().
>> * Add OVS_U128_MIN, OVS_U128_ZERO.
>> * Use HMAP_FOR_EACH_POP.
>> * Check that UDP length is valid.
>> * Style fix: prefer 'sizeof *object' instead of 'sizeof type'
>> * Don't accept packets from/to UDP/TCP port 0.
>> * Use defines for timeouts.
>> * Check expiration inside lookup loop in conn_key_lookup().
>> * Limit the number of connections.
>> * Simplify case if tcp_get_wscale().
>> * Introduce general INT_MOD_* macros for comparisons in modular
>> arithmetic.
>> * Improve comments.
>> * New cleanup mechanism: we keep connections in an ordered list and
>> we have
>>   a separate thread to performs the cleanup.  This doesn't block the
>> main
>>   thread for long intervals anymore.
>> * Correctly fill UDP length and UDP/TCP/ICMP checksums in
>> flow_compose():
>>   it's useful to write testcases for the connection tracker.
>> * Added system test with ICMP traffic through the connection tracker.
>> * Track ICMP type and code.
>> 
>> v1 -> v2:
>> * Fixed bug in tcp_get_wscale(), related to TCP options parsing.
>> * Changed names of ICMP constants: now they're different from Linux
>> and
>>   FreeBSD.
>> * Fixed bug in parse_ipv6_ext_hdrs().
>> * Used ALWAYS_INLINE in parse_vlan and parse_ethertype, to avoid a
>>   performance regression in miniflow_extract().
>> * Updated copyright info in COPYING and debian/copyright.in.
>> * Rebased.
>> * Changed batching strategy in conntrack_execute() to allow a newly
>>   created connection to be picked up by packets in the same batch.
>> * Added an ovs-test module to throw pcap files at the connection
>> tracker.
>> * Added a workaround for the userspace testsuite on new kernels and a
>> tcp
>>   non-conntrack test.
>> 
>> 
>> Daniele Di Proietto (16):
>>   packets: Define ICMP types.
>>   flow: Export parse_ipv6_ext_hdrs().
>>   flow: Introduce parse_dl_type().
>>   conntrack: Ne

Re: [ovs-dev] [PATCH] netdev-dpdk : vhost-user port link state fix

[Daniele Di Proietto]

Thanks for the patch!

I have a few comments inline, otherwise this looks good to me

2016-05-12 9:13 GMT-07:00 Zoltán Balogh :

> Hi,
>
> OVS reports that link state of a vhost-user port (type=dpdkvhostuser) is
> DOWN, even when traffic is running through the port between a Virtual
> Machine and the vSwitch.
> Changing admin state with the "ovs-ofctl mod-port   up/down"
> command over OpenFlow does affect neither the reported link state nor the
> traffic.
>
> The patch below does the flowing:
>  - Triggers link state change by altering netdev's change_seq member.
>  - Controls sending/receiving of packets through vhost-user port according
> to the port's current admin state.
>  - Sets admin state of newly created vhost-user port to UP.
>
> Signed-off-by: Zoltán Balogh 
> Co-authored-by: Jan Scheurich 
> Signed-off-by: Jan Scheurich 
>
> ---
>
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index af86d19..155efe1 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -772,6 +772,8 @@ netdev_dpdk_init(struct netdev *netdev, unsigned int
> port_no,
>  }
>  } else {
>  netdev_dpdk_alloc_txq(dev, OVS_VHOST_MAX_QUEUE_NUM);
> +/* Enable DPDK_DEV_VHOST device and set promiscuous mode flag. */
> +dev->flags = NETDEV_UP | NETDEV_PROMISC;
>  }
>
>  ovs_list_push_back(&dpdk_list, &dev->list_node);
> @@ -1256,6 +1258,21 @@ netdev_dpdk_vhost_rxq_recv(struct netdev_rxq *rxq,
>  return EAGAIN;
>  }
>
> +/* Delete received packets if device is disabled. */
> +if (OVS_UNLIKELY(!(dev->flags & NETDEV_UP))) {
> +uint16_t i;
> +
> +VLOG_WARN_RL(&rl, "error receiving Ethernet packet on %s: %s",
> + netdev_rxq_get_name(rxq), ovs_strerror(ENONET));
> +
> +for (i = 0; i < nb_rx; i++) {
> +dp_packet_delete(packets[i]);
> +}
> +
> +*c = 0;
> +return EAGAIN;
> +}
> +
>

Is there a particular reason we need to call rte_vhost_dequeue_burst() and
then
delete the packets?

A few lines above, we already have

if (OVS_UNLIKELY(!is_vhost_running(virtio_dev))) {

we might as well check for NETDEV_UP there.

Also, I don't think we should log a warning if the device is disabled.

 rte_spinlock_lock(&dev->stats_lock);
>  netdev_dpdk_vhost_update_rx_counters(&dev->stats, packets, nb_rx);
>  rte_spinlock_unlock(&dev->stats_lock);
> @@ -1516,6 +1533,23 @@ static int
>  netdev_dpdk_vhost_send(struct netdev *netdev, int qid, struct dp_packet
> **pkts,
>   int cnt, bool may_steal)
>  {
> +struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
> +
> +/* Do not send anything if device is disabled. */
> +if (OVS_UNLIKELY(!(dev->flags & NETDEV_UP))) {
> +int i;
> +
> +VLOG_WARN_RL(&rl, "error sending Ethernet packet on %s: %s",
> + netdev_get_name(netdev), ovs_strerror(ENONET));
> +
> +if (may_steal) {
> +for (i = 0; i < cnt; i++) {
> +dp_packet_delete(pkts[i]);
> +}
> +}
> +return ENONET;
> +}
> +
>

In __netdev_dpdk_vhost_send() we have this check:

if (OVS_UNLIKELY(!is_vhost_running(virtio_dev) || qid < 0)) {

I think we should check for NETDEV_UP there and avoid printing the warning.


>  if (OVS_UNLIKELY(pkts[0]->source != DPBUF_DPDK)) {
>  int i;
>
> @@ -2004,6 +2038,23 @@ netdev_dpdk_update_flags__(struct netdev_dpdk *dev,
>  if (!(dev->flags & NETDEV_UP)) {
>  rte_eth_dev_stop(dev->port_id);
>  }
> +} else {
> +/* If DPDK_DEV_VHOST device's NETDEV_UP flag was changed and
> vhost is
> + * running then change netdev's change_seq to trigger link state
> + * update. */
> +struct virtio_net *virtio_dev = netdev_dpdk_get_virtio(dev);
> +
> +if ((NETDEV_UP & ((*old_flagsp ^ on) | (*old_flagsp ^ off)))
> +&& is_vhost_running(virtio_dev)) {
> +netdev_change_seq_changed(&dev->up);
> +
> +/* Clear statistics if device is getting up. */
> +if (NETDEV_UP & on) {
> +rte_spinlock_lock(&dev->stats_lock);
> +memset(&dev->stats, 0x00, sizeof(dev->stats));
>

Could you use 0, instead of 0x00?


> +rte_spinlock_unlock(&dev->stats_lock);
> +}
> +}
>  }
>
>  return 0;
> @@ -2226,6 +2277,7 @@ new_device(struct virtio_net *virtio_dev)
>  virtio_dev->flags |= VIRTIO_DEV_RUNNING;
>  /* Disable notifications. */
>  set_irq_status(virtio_dev);
> +netdev_change_seq_changed(&dev->up);
>  ovs_mutex_unlock(&dev->mutex);
>  break;
>  }
> @@ -2277,6 +2329,7 @@ destroy_device(volatile struct virtio_net
> *virtio_dev)
>  ovsrcu_set(&dev->virtio_dev, NULL);
>  netdev_dpdk_txq_map_clear(dev);
>  exists = true;
> +netdev_change_seq_changed(&dev->up);
>

Re: [ovs-dev] [PATCH] acinclude: fix issue when configuring with --with-dpdk

[Mauricio Vásquez]

Hi Ben,

On Wed, Jun 1, 2016 at 7:38 PM, Ben Pfaff  wrote:

> On Wed, Jun 01, 2016 at 06:48:07PM +0200, Mauricio Vasquez B wrote:
> > when an empty path is given to the --with-dpdk option
> > (--with-dpdk="" or --width-dpdk=$NON_SET_ENV_VARIABLE) the configure
> > script does not show any error and configures OvS without DPDK support,
> > this can create some confusion.
> >
> > This patch modifies that behavior showing an explicity error in that
> case.
> >
> > Signed-off-by: Mauricio Vasquez B <
> mauricio.vasquezber...@studenti.polito.it>
>
> Doesn't apply, please send a patch against current master.
>
>
I'm lost, you already applied it to master. Was this email for somebody
else?


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

Re: [ovs-dev] [PATCH monitor_cond V6 01/11] ovsdb: create column index mapping between ovsdb row to monitor row

[Ben Pfaff]

On Tue, May 17, 2016 at 05:26:59PM +0300, Liran Schour wrote:
> Columns indexing is different in ovsdb_row then in ovsdb_monitor_row.
> We need mapping between the 2 for condition evaluation.
> 
> signed-off-by: Liran Schour 

In ovsdb_monitor_table_columns_sort(), I don't understand why this loop
starts at 1 instead of 0:
> +qsort(mt->columns, mt->n_columns, sizeof *mt->columns,
> +  compare_ovsdb_monitor_column);
> +for (i = 1; i < mt->n_columns; i++) {
> +/* re-set index map due to sort */
> +mt->columns_index_map[mt->columns[i].column->index] = i;
> +}

In ovsdb_monitor_add_table(), please use sizeof *mt->columns_index_map
instead of sizeof(unsigned int), following CodingStyle.md:
+mt->columns_index_map =
+xmalloc(sizeof(unsigned int) * shash_count(&table->schema->columns));

Also in ovsdb_monitor_add_table(), I think that the code would be a
little easier to read if shash_count(&table->schema->columns) were put
into a variables, e.g. n_columns.

This new columns_index_map means that it's no longer necessary to work
so hard to find duplicates--rather, we can find a duplicate at the time
we try to add a column: a new column is a duplicate if
columns_index_map[column->index] != -1 at the time we try to add it.  It
would probably be nicer to simply report the error at the time we add
it, instead of adding a sort step and a re-indexing step.

Please add a period at the end of this comment, to make it look like a
complete thought:
+/* Columns in ovsdb_monitor_row have different indexes then in
+ * ovsdb_row. This field maps between column->index to the index in the
+ * ovsdb_monitor_row. It is used for condition evaluation */

Thanks,

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

Re: [ovs-dev] [PATCH v2 0/2] vhost-user: Add the ability to control ownership/permissions

[Ansis Atteka]

On 20 May 2016 at 13:32, Aaron Conole  wrote:

> Currently, when using Open vSwitch with DPDK and qemu guests, the
> recommended
> method for joining the guests is via the dpdkvhostuser interface. This
> interface uses Unix Domain sockets to communicate. When these sockets are
> created, they inherit the permissions and ownership from the vswitchd
> process.
> This can lead to an undesirable state where the QEMU process cannot use the
> socket file until manual intervention is performed (via `chown` and/or
> `chmod`
> calls).
>

Hi Aaron,

Could you explain:
1. who would be setting the owner via this newly introduced OVSDB interface?
2. who would be starting the QEMU process for use-cases you are trying to
solve here?

I am asking this because in another thread [
http://openvswitch.org/pipermail/dev/2016-June/071935.html] I had
discussion with Libvirt folks and they explained to me that under their
current security model they think it should be Libvirt doing the actual
chown() calls and that they would prefer not use Open vSwitch as a proxy to
do it for them. This is at least what they apparently have been doing all
this time to lock down privileges for QEMU processes.

Some food for thoughts:
1. What, if in future Libvirt will chown() the DPDK sockets directly and
override the value set in OVSDB (assuming QEMU is started by libvirt, but
ovs-vsctl is invoked by some other process)?
2. What about Mandatory Access Control security context (the one you see in
`ls -Z ` output on RHEL-type distributions)? Do you plan to set it as
well in the future from ovs-vswitchd? MAC is another security layer that
Libvirt uses to confine QEMU.
3. Also this patch kinda conflicts with --user flag because then ovs user
would have to be put under "qemu" group to be able to chown sockets to
"qemu" user. This reexposes OVS to untrusted resources owned by qemu user.
Anyway this flag does not work with DPDK anyway and I think we may want to
deprecate it.

Also what you have may be completely fine:
1. as a short term solution for Libvirt if it currently does not chown()
DPDK sockets; OR
2. if you are targeting this feature for hypervisors that are not using
Libvirt and have completely different security model.

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

Re: [ovs-dev] [PATCH monitor_cond V6 00/11] Implement conditional monitoring

[Ben Pfaff]

On Tue, May 17, 2016 at 05:26:58PM +0300, Liran Schour wrote:
> This patch series implements conditional monitoring by introducing an OVSDB
> RFC extension with 2 new JSON-RPC methods: "monitor_cond" and
> "monitor_cond_update". Specification of this extension is defined in the
> ovsdb-server (1) man page.
> Monitor2 is now merged into monitor_cond. A monitor_cond session with an 
> empty 
> condition, will behave exactly like monitor2 and will get update2 
> notifications
> on all rows.
> 
> This patch series is also available on: https://github.com/liranschour/ovs.git
> branch monitor_cond_ovn.

Hi Liran, thanks for the new version of the patch series, and sorry that
it's taken a while to review it.  I'm reviewing it today based on the
branch listed above, as fetched a few minutes ago.

I did a build on the series as a whole.  "sparse" issues some warnings.
Probably these variables should be declared "static":

../ovn/controller/binding.c:151:13: warning: symbol 'g_lports' was not 
declared. Should it be static?
../ovn/controller/binding.c:232:13: warning: symbol 'g_peer_lports' was not 
declared. Should it be static?

I ran the tests and they passed.

I'll review each of the patches now.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] acinclude: fix issue when configuring with --with-dpdk

[Ben Pfaff]

On Wed, Jun 01, 2016 at 06:48:07PM +0200, Mauricio Vasquez B wrote:
> when an empty path is given to the --with-dpdk option
> (--with-dpdk="" or --width-dpdk=$NON_SET_ENV_VARIABLE) the configure
> script does not show any error and configures OvS without DPDK support,
> this can create some confusion.
> 
> This patch modifies that behavior showing an explicity error in that case.
> 
> Signed-off-by: Mauricio Vasquez B 

Doesn't apply, please send a patch against current master.

Thanks,

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

Re: [ovs-dev] [PATCH] system-tests: fix module removal during cleanup

[Joe Stringer]

On 23 May 2016 at 17:57, Thadeu Lima de Souza Cascardo
 wrote:
> Currently, cleanup files for system tests will look like this:
>
> modprobe -q -r vport_vxlan
> modprobe -q -r vport_sttmodprobe
> modprobe -q -r vport_lispmodprobe
> modprobe -q -r vport_gremodprobe
> modprobe -q -r vport_genevemodprobe
> modprobe -r openvswitch
>
> This is caused by a missing newline in m4_foreach EXPRESSION and the fact that
> on_exit is a shell function. It was being expanded like this:
>
> on_exit 'modprobe -q -r vport_genevemodprobe' -q vport_gre
>
> Fixes: 53eb8cb83013 ("tests: Replace ON_EXIT m4 macro by on_exit() shell 
> function.")
> Signed-off-by: Thadeu Lima de Souza Cascardo 

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

Re: [ovs-dev] [PATCH v2 2/3] datapath-windows: Fix alignment on Offload.c

[Ben Pfaff]

On Tue, May 24, 2016 at 04:14:26PM +, Alin Serdean wrote:
> Found by inspection.
> 
> Signed-off-by: Alin Gabriel Serdean 
> Acked-by: Nithin Raju 

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

Re: [ovs-dev] [PATCH v2 1/3] datapath-windows: Add UDP checksum verifications for VXLAN

[Ben Pfaff]

On Tue, May 24, 2016 at 04:14:19PM +, Alin Serdean wrote:
> Introduce UDP checksum if it was specified in the tunnel information
> on Tx.
> 
> Set the tunnel checksum information flag on the flow if the
> UDP checksum was non zero on the Rx.
> 
> Signed-off-by: Alin Gabriel Serdean 

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

[ovs-dev] [patch_v1] ovn: Fix receive from vxlan in ovn-controller.

[Darrell Ball]

OVN only supports source_node replication and previously vtep interaction,
which used service node replication by default for multicast/broadcast/unknown
unicast traffic worked by happenstance.  Because of limited vxlan
encapsulation metadata, received packets were resubmitted to find the egress
port(s). This is not correct for multicast, broadcast and unknown unicast 
traffic
as traffic will get resent on the tunnel mesh. ovn-controller is changed not to
send traffic received from vxlan tunnels out the tunnel mesh again.  Traffic
received from vxlan tunnels is now only sent locally as intended.

To support keeping state for receipt from a vxlan tunnel a MFF logical
register is allocated for general scratchpad purposes and one bit is used for
receipt from vxlan.  The new register usage is documented in a new
OVN-DESIGN.md document and a table is added to track MFF logical metadata
and register usage.

As part of this change ovn-controller-vtep is hard-coded to set the replication
mode of each logical switch to source node as OVN will only support source
node replication.

Signed-off-by: Darrell Ball 
---
 ovn/OVN-DESIGN.md  | 170 +++
 ovn/automake.mk|   1 +
 ovn/controller-vtep/vtep.c |   5 ++
 ovn/controller/physical.c  |  32 ++--
 ovn/lib/logical-fields.h   |  18 -
 ovn/ovn-architecture.7.xml | 178 -
 tests/ovn.at   |   3 +
 7 files changed, 222 insertions(+), 185 deletions(-)
 create mode 100644 ovn/OVN-DESIGN.md

diff --git a/ovn/OVN-DESIGN.md b/ovn/OVN-DESIGN.md
new file mode 100644
index 000..2bfdf3e
--- /dev/null
+++ b/ovn/OVN-DESIGN.md
@@ -0,0 +1,170 @@
+OVN register and metadata usage:
+---
+
+logical datapath field:
+
+A field that denotes the logical datapath through which a packet is being
+processed.
+
+OVN uses the field that OpenFlow 1.1+ simply (and confusingly) calls
+'metadata' to store the logical datapath.  (This field is passed across
+tunnels as part of the tunnel key.)
+
+
+logical input port field:
+
+A field that denotes the logical port from which the packet entered the
+logical datapath.
+
+OVN stores this in Nicira extension register number 6.
+
+Geneve and STT tunnels pass this field as part of the tunnel key.
+Although VXLAN tunnels do not explicitly carry a logical input port,
+OVN only uses VXLAN to communicate with gateways that from OVN's
+perspective consist of only a single logical port, so that OVN can set
+the logical input port field to this one on ingress to the OVN logical
+pipeline.
+
+
+logical output port field:
+
+A field that denotes the logical port from which the packet will leave
+the logical datapath.  This is initialized to 0 at the beginning of the
+logical ingress pipeline.
+
+OVN stores this in Nicira extension register number 7.
+
+Geneve and STT tunnels pass this field as part of the tunnel key.  VXLAN
+tunnels do not transmit the logical output port field.
+
+
+conntrack zone field:
+
+A field that denotes the connection tracking zone.  The value only
+has local significance and is not meaningful between chassis.
+This is initialized to 0 at the beginning of the logical ingress
+pipeline.  OVN stores this in Nicira extension register number 5.
+
+
+flags field:
+
+Scratchpad flags that denote the pipeline state between tables.  The
+values only have local significance and are not meaningful between
+chassis.  This is initialized to 0 at the beginning of the logical
+ingress pipeline. 
+
+OVN stores this in Nicira extension register number 4.
+
+
+VLAN ID:
+
+The VLAN ID is used as an interface between OVN and containers nested
+inside a VM (see Life Cycle of a container interface inside a VM, in 
+ovn-architecture.7.xml, for more information).
+
+
+The following table summarizes the register and metadata usage for OVN:
+
+```
+  Register/Metadata Usage  Bits (Used/Total)
+  ---
+  MFF_METADATA logical datapath field24/64
+  MFF_REG0 ipv4 address  32/32
+  MFF_REG1 ipv4 address  32/32
+  MFF_REG2 unassigned 0/32
+  MFF_REG3 unassigned 0/32
+  MFF_REG4 flags field1/32
+  MFF_REG5 conntrack zone field  16/32
+  MFF_REG6 logical input port field  15/32
+  MFF_REG7 logical output port field 16/32
+```
+
+OVN Tunnel Encapsulations:
+-
+
+tunnel key:
+
+When OVN encapsulates a packet in Geneve or another tunnel, it attaches
+extra data to it to allow the receiving OVN instance to process it
+correctly.  This takes different forms depending on the particular
+encapsulation, but in each case we refer to it

Re: [ovs-dev] [PATCH 1/2] [PATCH v5] datapath-windows: Move UDP checksum computation to Offload.c

[Ben Pfaff]

On Tue, May 24, 2016 at 11:28:03PM +, Yin Lin wrote:
> UDP checksum computation is shared by both vxlan and geneve on Windows.
> Move the function so that the code can be shared.
> 
> Signed-off-by: Yin Lin

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

[ovs-dev] [PATCH] ovs-tcpdump: Add a tcpdump wrapper utility

[Aaron Conole]

Currently, there is some documentation which describes setting up and
using port mirrors for bridges. This documentation is helpful to setup
a packet capture for specific ports.

However, a utility to do such packet capture would be valuable, both
as an exercise in documenting the steps an additional time, and as a way
of providing an out-of-the-box experience for running a capture.

This commit adds a tcpdump-wrapper utility for such purpose. It uses the
Open vSwitch python library to add/remove ports and mirrors to/from the
Open vSwitch database. It will create a tcpdump instance listening on
the mirror port (allowing the user to specify additional arguments), and
dump data to the screen (or otherwise).

Signed-off-by: Aaron Conole 
---
 NEWS   |   2 +
 utilities/automake.mk  |   8 +-
 utilities/ovs-tcpdump.8.in |  51 +
 utilities/ovs-tcpdump.in   | 453 +
 4 files changed, 513 insertions(+), 1 deletion(-)
 create mode 100644 utilities/ovs-tcpdump.8.in
 create mode 100755 utilities/ovs-tcpdump.in

diff --git a/NEWS b/NEWS
index ba201cf..042b361 100644
--- a/NEWS
+++ b/NEWS
@@ -55,6 +55,8 @@ Post-v2.5.0
  * Flow based tunnel match and action can be used for IPv6 address using
tun_ipv6_src, tun_ipv6_dst fields.
  * Added support for IPv6 tunnels to native tunneling.
+   - A wrapper script, 'ovs-tcpdump', to easily port-mirror an OVS port and
+ watch with tcpdump
 
 v2.5.0 - 26 Feb 2016
 -
diff --git a/utilities/automake.mk b/utilities/automake.mk
index 1cc66b6..d703d31 100644
--- a/utilities/automake.mk
+++ b/utilities/automake.mk
@@ -12,6 +12,7 @@ bin_SCRIPTS += \
utilities/ovs-l3ping \
utilities/ovs-parse-backtrace \
utilities/ovs-pcap \
+   utilities/ovs-tcpdump \
utilities/ovs-tcpundump \
utilities/ovs-test \
utilities/ovs-vlan-test
@@ -52,6 +53,7 @@ EXTRA_DIST += \
utilities/ovs-pipegen.py \
utilities/ovs-pki.in \
utilities/ovs-save \
+   utilities/ovs-tcpdump.in \
utilities/ovs-tcpundump.in \
utilities/ovs-test.in \
utilities/ovs-vlan-test.in \
@@ -69,6 +71,7 @@ MAN_ROOTS += \
utilities/ovs-parse-backtrace.8 \
utilities/ovs-pcap.1.in \
utilities/ovs-pki.8.in \
+   utilities/ovs-tcpdump.8.in \
utilities/ovs-tcpundump.1.in \
utilities/ovs-vlan-bug-workaround.8.in \
utilities/ovs-test.8.in \
@@ -94,6 +97,8 @@ DISTCLEANFILES += \
utilities/ovs-pki.8 \
utilities/ovs-sim \
utilities/ovs-sim.1 \
+   utilities/ovs-tcpdump \
+   utilities/ovs-tcpdump.8 \
utilities/ovs-tcpundump \
utilities/ovs-tcpundump.1 \
utilities/ovs-test \
@@ -148,6 +153,7 @@ utilities_nlmon_LDADD = lib/libopenvswitch.la
 endif
 
 FLAKE8_PYFILES += utilities/ovs-pcap.in \
-   utilities/checkpatch.py utilities/ovs-dev.py
+   utilities/checkpatch.py utilities/ovs-dev.py \
+   utilities/ovs-tcpdump.in
 
 include utilities/bugtool/automake.mk
diff --git a/utilities/ovs-tcpdump.8.in b/utilities/ovs-tcpdump.8.in
new file mode 100644
index 000..ecd0937
--- /dev/null
+++ b/utilities/ovs-tcpdump.8.in
@@ -0,0 +1,51 @@
+.TH ovs\-tcpdump 8 "@VERSION@" "Open vSwitch" "Open vSwitch Manual"
+.
+.SH NAME
+ovs\-tcpdump \- Dump traffic from an Open vSwitch port using \fBtcpdump\fR.
+.
+.SH SYNOPSIS
+\fBovs\-tcpdump\fR \fB\-i\fR \fIport\fR \fBtcpdump options...\fR
+.
+.SH DESCRIPTION
+\fBovs\-tcpdump\fR creates switch mirror ports in the \fBovs\-vswitchd\fR
+daemon and executes \fBtcpdump\fR to listen against those ports. When the
+\fBtcpdump\fR instance exits, it then cleans up the mirror port it created.
+.PP
+\fBovs\-tcpdump\fR will not allow multiple mirrors for the same port. It has
+some logic to parse the current configuration and prevent duplicate mirrors.
+.PP
+The \fB\-i\fR option may not appear multiple times.
+.PP
+It is important to note that under \fBLinux\fR based kernels, tap devices do
+not receive packets unless the specific tuntap device has been opened by an
+application. This requires \fBCAP_NET_ADMIN\fR privileges, so the
+\fBovs-tcpdump\fR command must be run as a user with such permissions (this
+is usually a super-user).
+.
+.SH "OPTIONS"
+.so lib/common.man
+.
+.IP "\fB\-\-db\-sock\fR"
+The Open vSwitch database socket connection string. The default is
+\fIunix:@RUNDIR@/db.sock\fR
+.
+.IP "\fB\-\-dump\-cmd\fR"
+The command to run instead of \fBtcpdump\fR.
+.
+.IP "\fB\-i\fR"
+.IQ "\fB\-\-interface\fR"
+The interface for which a mirror port should be created, and packets should
+be dumped.
+.
+.IP "\fB\-\-mirror\-to\fR"
+The name of the interface which should be the destination of the mirrored
+packets. The default is miINTERFACE
+.
+.SH "SEE ALSO"
+.
+.BR ovs\-appctl (8),
+.BR ovs\-vswitchd (8),
+.BR ovs\-pcap (1),
+.BR ovs\-tcpundump (1),
+.BR tcpdump (8),
+.BR wireshark (8).
diff --git a/utilitie

Re: [ovs-dev] [PATCH] acinclude: fix issue when configuring with --with-dpdk

[Ben Pfaff]

On Wed, Jun 01, 2016 at 06:48:07PM +0200, Mauricio Vasquez B wrote:
> when an empty path is given to the --with-dpdk option
> (--with-dpdk="" or --width-dpdk=$NON_SET_ENV_VARIABLE) the configure
> script does not show any error and configures OvS without DPDK support,
> this can create some confusion.
> 
> This patch modifies that behavior showing an explicity error in that case.
> 
> Signed-off-by: Mauricio Vasquez B 

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

[ovs-dev] [PATCH] acinclude: fix issue when configuring with --with-dpdk

[Mauricio Vasquez B]

when an empty path is given to the --with-dpdk option
(--with-dpdk="" or --width-dpdk=$NON_SET_ENV_VARIABLE) the configure
script does not show any error and configures OvS without DPDK support,
this can create some confusion.

This patch modifies that behavior showing an explicity error in that case.

Signed-off-by: Mauricio Vasquez B 
---
 acinclude.m4 | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/acinclude.m4 b/acinclude.m4
index f3de855..0a14856 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -161,10 +161,11 @@ dnl Configure DPDK source tree
 AC_DEFUN([OVS_CHECK_DPDK], [
   AC_ARG_WITH([dpdk],
   [AC_HELP_STRING([--with-dpdk=/path/to/dpdk],
-  [Specify the DPDK build directory])])
+  [Specify the DPDK build directory])],
+  [have_dpdk=true])
 
   AC_MSG_CHECKING([whether dpdk datapath is enabled])
-  if test -z "$with_dpdk" || test "$with_dpdk" = no; then
+  if test "$have_dpdk" != true || test "$with_dpdk" = no; then
 AC_MSG_RESULT([no])
 DPDKLIB_FOUND=false
   else
-- 
1.9.1

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

Re: [ovs-dev] [PATCH 2/2] doc: Refactor DPDK install guide, add ADVANCED doc

[Bodireddy, Bhanuprakash]

>-Original Message-
>From: Flavio Leitner [mailto:f...@sysclose.org]
>Sent: Tuesday, May 31, 2016 10:04 PM
>To: Bodireddy, Bhanuprakash 
>Cc: dev@openvswitch.org; Traynor, Kevin 
>Subject: Re: [ovs-dev] [PATCH 2/2] doc: Refactor DPDK install guide, add
>ADVANCED doc
>
>
>This looks very good and I just have two minor comment below.
>
>On Thu, May 26, 2016 at 01:46:43PM +0100, Bhanuprakash Bodireddy wrote:
>> Add INSTALL.DPDK-ADVANCED document that is forked off from original
>> INSTALL.DPDK guide. This document is targeted at users looking for
>> optimum performance on OVS using dpdk datapath.
>>
>> Signed-off-by: Bhanuprakash Bodireddy
>> 
>> ---
>[...]
>
>> +  5. Running sample "dpdk ring" app in VM
>> +
>> +   ```
>> +   umount /dev/hugepages
>> +   mount -t hugetlbfs hugetlbfs /mnt/hugepages
>> +   ln -s /sys/devices/pci:00/:00:04.0/resource2
>/dev/hugepages/rtemap_0
>> +   mount -o iocharset=utf8 /dev/sdb1 /mnt/ovs
>> +   cp /mnt/ovs/.rte_config /run/.
>> +   cp /mnt/ovs/.rte_hugepage_info /run/.
>> +
>> +   # Build the DPDK ring application in the VM
>> +   export RTE_SDK=/root/dpdk-16.04
>> +   export RTE_TARGET=x86_64-ivshmem-linuxapp-gcc
>> +   make
>> +
>> +   # Run dpdkring application
>> +   ./build/dpdkr -c 1 -n 4 --proc-type=secondary -- -n 0
>> +   where "-n 0" refers to ring '0' i.e dpdkr0
>> +   ```
>> +
>> +##  6. Vhost Walkthrough
>> +
>> +DPDK 16.04 supports two types of vhost:
>> +1. vhost-user - enabled default
>> +2. vhost-cuse - Legacy, disabled by default
>
>That doesn't show nicely on the web. They are all in the same line.

You are right, I will correct this.

>
>The same comment for the previous patch about the mount command in
>''Mount huge pages'' here.  Just add 'if not mounted'  or something like that.

Agree, Will add this.

Thanks Flavio for reviewing the ADVANCED guide. 

Regards,
Bhanu Prakash.

>
>Thanks,
>--
>fbl

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

Re: [ovs-dev] [PATCH 1/2] doc: Refactor DPDK install documentation

[Bodireddy, Bhanuprakash]

Thanks Flavio for reviewing the install guide in detail. My comments inline.

>-Original Message-
>From: Flavio Leitner [mailto:f...@sysclose.org]
>Sent: Tuesday, May 31, 2016 9:44 PM
>To: Bodireddy, Bhanuprakash 
>Cc: dev@openvswitch.org; Traynor, Kevin 
>Subject: Re: [ovs-dev] [PATCH 1/2] doc: Refactor DPDK install documentation
>
>
>Hi,
>
>Thanks for doing this.
>I have some comments inline.
>fbl
>
>
>On Thu, May 26, 2016 at 01:46:42PM +0100, Bhanuprakash Bodireddy wrote:
>> Refactor the INSTALL.DPDK in to two documents named INSTALL.DPDK and
>> INSTALL.DPDK-ADVANCED. While INSTALL.DPDK document shall facilitate
>the
>> novice user in setting up the OVS DPDK and running it out of box, the
>> ADVANCED document is targeted at expert users looking for the optimum
>> performance running dpdk datapath.
>>
>> This commit updates INSTALL.DPDK.md document.
>>
>> Signed-off-by: Bhanuprakash Bodireddy
>
>> ---
>>  INSTALL.DPDK.md | 1299 ++
>-
>>  1 file changed, 429 insertions(+), 870 deletions(-)
>>
>> diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
>> index 68735cc..561631f 100644
>> --- a/INSTALL.DPDK.md
>> +++ b/INSTALL.DPDK.md
>> @@ -1,1020 +1,579 @@
>> -Using Open vSwitch with DPDK
>> -
>> +OVS DPDK INSTALL GUIDE
>> +
>>
>> -`./testpmd -c 0x3 -n 4 --socket-mem 512 -- --burst=64 -i --
>txqflags=0xf00 --disable-hw-vlan --forward-mode=io --auto-start`
>> + Note: For IVSHMEM, Set `export DPDK_TARGET=x86_64-ivshmem-
>linuxapp-gcc`
>>
>> -See below information on dpdkvhostcuse and dpdkvhostuser ports.
>> -See [DPDK Docs] for more information on `testpmd`.
>> +### 2.3 Install OVS
>
>It seems to me that this section could be better.  We have a good INSTALL.md
>file covering all options, additional details and also have pointers to more
>specifics like how to do in Fedora or Debian.
>
>For instance, Fedora spec file in branch master allows you to build with
>DPDK support with a simple command line:
>
>   $ make rpm-fedora RPMBUILD_OPT="--with dpdk"
>
>Nothing wrong documenting a generic recipe, but I missed the other
>options.  Perhaps something like:
>
>2.3 Install OVS
>   OVS can be installed using different methods. The only requirement to
>install
>with DPDK support enabled is to pass an extra argument to ./configure.  You
>can find
>additional information in INSTALL.md or more specific instructions for a
>distribution
>in the other INSTALL.*.md files available in the repository.  This documents
>focus on
>a generic recipe that should work for most cases

Good point, I will rework this section keeping your comments in mind. Also I 
would add hyperlinks to 
INSTALL.md and would redirect users doing distribution specific builds to 
respective pages. 

>
>I am sure it can be reworded in a better way, but it shows my point.
>
>
>> +  OVS can be downloaded in compressed format from the OVS release
>page (or)
>> +  cloned from git repository if user intends to develop and contribute
>> +  patches upstream.
>>
>> +  - [Download OVS] tar ball and extract the file, for example in to /usr/src
>> + and set OVS_DIR
>>
>> + ```
>> + wget -O ovs.tar https://github.com/openvswitch/ovs/tarball/master
>> + mkdir -p /usr/src/ovs
>> + tar -xvf ovs.tar -C /usr/src/ovs --strip-components=1
>> + export OVS_DIR=/usr/src/ovs
>> + ```
>>
>> -DPDK Rings :
>> -
>> +  - Clone the Git repository for OVS, for example in to /usr/src
>>
>> -Following the steps above to create a bridge, you can now add dpdk rings
>> -as a port to the vswitch.  OVS will expect the DPDK ring device name to
>> -start with dpdkr and end with a portid.
>> + ```
>> + cd /usr/src/
>> + git clone https://github.com/openvswitch/ovs.git
>> + export OVS_DIR=/usr/src/ovs
>> + ```
>>
>> -`ovs-vsctl add-port br0 dpdkr0 -- set Interface dpdkr0 type=dpdkr`
>> +  - Install OVS dependencies
>>
>> -DPDK rings client test application
>> + GNU make, GCC 4.x (or) Clang 3.4  (Mandatory)
>> + libssl, libcap-ng, Python 2.7  (Optional)
>> + More information can be found at [Build Requirements]
>>
>> -Included in the test directory is a sample DPDK application for testing
>> -the rings.  This is from the base dpdk directory and modified to work
>> -with the ring naming used within ovs.
>> +  - Configure, Install OVS
>>
>> -location tests/ovs_client
>> + ```
>> + cd $OVS_DIR
>> + ./boot.sh
>> + ./configure --with-dpdk=$DPDK_BUILD
>> + make install
>> + ```
>>
>> -To run the client :
>> + Note: Passing DPDK_BUILD can be skipped if DPDK library is installed in
>> + standard locations i.e `./configure --with-dpdk` should suffice.
>>
>> -```
>> -cd /usr/src/ovs/tests/
>> -ovsclient -c 1 -n 4 --proc-type=secondary -- -n "port id you gave dpdkr"
>> -```
>> +##  3. Setup OVS with DPDK datapath
>>
>> -In the case of the dpdkr example above the "port id you g

[ovs-dev] Supply Chain Management

[Julia Perez]

Did you get a chance to review my previous email? Please let me know if you did 
like to review few sample records from your target audience.

Look forward to hearing back.

Regards,

Julia
_
From: Julia Perez
Sent: Friday, May 27, 2016 10:06 AM
To: dev@openvswitch.org
Subject: Supply Chain Management

Hi,

Would you be interested in an email leads of Supply Chain Executives? We can 
help you reach out to.

Title includes:

>  VP of Supply Chain

>  Director of Supply Chain

>  Supply Chain Manager

>  Purchasing Manager

>  Purchasing Director

>  Procurement Manager

>  Procurement Director

The list comes with complete contact information like Contact name, Email 
address, Title, Company name, Phone number, Mailing address, etc.

I'd be happy to send over few sample records on your request, and set up a time 
to discuss further.

If there is someone else in your organization that I need to speak with, I'd be 
grateful if you would forward this email to the appropriate contact and help me 
with the introduction.

Have a great day!


Regards,

Julia Perez / INF Solutions / 302-250-4336
If you don't wish to receive emails from us reply back with "Unsubscribe".


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

[ovs-dev] [PATCH v2] datapath-windows: Sample action support.

[Sorin Vinturis]

This patch adds support for sampling to the OVS extension.

The following flow was used for generating sample actions:
  ovs-ofctl add-flow tcp:127.0.0.1: "actions=sample(
probability=12345,collector_set_id=23456,obs_domain_id=34567,
obs_point_id=45678)"

Signed-off-by: Sorin Vinturis 
---
v2: Moved random functions to Util.h and removed Random.h.
---
 datapath-windows/ovsext/Actions.c | 181 +++---
 datapath-windows/ovsext/Util.h|  27 ++
 2 files changed, 175 insertions(+), 33 deletions(-)

diff --git a/datapath-windows/ovsext/Actions.c 
b/datapath-windows/ovsext/Actions.c
index 4edf7d0..1e894eb 100644
--- a/datapath-windows/ovsext/Actions.c
+++ b/datapath-windows/ovsext/Actions.c
@@ -1596,6 +1596,131 @@ OvsExecuteHash(OvsFlowKey *key,
 hash = 1;
 
 key->dpHash = hash;
+}
+
+/*
+ * --
+ * OvsOutputUserspaceAction --
+ *  This function sends the packet to userspace according to nested
+ *  %OVS_USERSPACE_ATTR_* attributes.
+ * --
+ */
+static __inline NDIS_STATUS
+OvsOutputUserspaceAction(OvsForwardingContext *ovsFwdCtx,
+ OvsFlowKey *key,
+ const PNL_ATTR attr)
+{
+NTSTATUS status = NDIS_STATUS_SUCCESS;
+PNL_ATTR userdataAttr;
+PNL_ATTR queueAttr;
+POVS_PACKET_QUEUE_ELEM elem;
+POVS_PACKET_HDR_INFO layers = &ovsFwdCtx->layers;
+BOOLEAN isRecv = FALSE;
+
+POVS_VPORT_ENTRY vport = OvsFindVportByPortNo(ovsFwdCtx->switchContext,
+  ovsFwdCtx->srcVportNo);
+
+if (vport) {
+if (vport->isExternal ||
+OvsIsTunnelVportType(vport->ovsType)) {
+isRecv = TRUE;
+}
+}
+
+queueAttr = NlAttrFindNested(attr, OVS_USERSPACE_ATTR_PID);
+userdataAttr = NlAttrFindNested(attr, OVS_USERSPACE_ATTR_USERDATA);
+
+elem = OvsCreateQueueNlPacket(NlAttrData(userdataAttr),
+  NlAttrGetSize(userdataAttr),
+  OVS_PACKET_CMD_ACTION,
+  vport, key, ovsFwdCtx->curNbl,
+  NET_BUFFER_LIST_FIRST_NB(ovsFwdCtx->curNbl),
+  isRecv,
+  layers);
+if (elem) {
+LIST_ENTRY missedPackets;
+InitializeListHead(&missedPackets);
+InsertTailList(&missedPackets, &elem->link);
+OvsQueuePackets(&missedPackets, 1);
+} else {
+status = NDIS_STATUS_FAILURE;
+}
+
+return status;
+}
+
+/*
+ * --
+ * OvsExecuteSampleAction --
+ *  Executes actions based on probability, as specified in the nested
+ *  %OVS_SAMPLE_ATTR_* attributes.
+ * --
+ */
+static __inline NDIS_STATUS
+OvsExecuteSampleAction(OvsForwardingContext *ovsFwdCtx,
+   OvsFlowKey *key,
+   const PNL_ATTR attr)
+{
+PNET_BUFFER_LIST newNbl = NULL;
+PNL_ATTR actionsList = NULL;
+PNL_ATTR a = NULL;
+INT rem = 0;
+
+SRand();
+NL_ATTR_FOR_EACH_UNSAFE(a, rem, NlAttrData(attr), NlAttrGetSize(attr)) {
+switch (NlAttrType(a)) {
+case OVS_SAMPLE_ATTR_PROBABILITY:
+{
+UINT32 probability = NlAttrGetU32(a);
+
+if (!probability || Rand() > probability) {
+return 0;
+}
+break;
+}
+case OVS_SAMPLE_ATTR_ACTIONS:
+actionsList = a;
+break;
+}
+}
+
+if (actionsList) {
+rem = NlAttrGetSize(actionsList);
+a = (PNL_ATTR)NlAttrData(actionsList);
+}
+
+if (!rem) {
+/* Actions list is empty, do nothing */
+return STATUS_SUCCESS;
+}
+
+/*
+ * The only known usage of sample action is having a single user-space
+ * action. Treat this usage as a special case.
+ */
+if (NlAttrType(a) == OVS_ACTION_ATTR_USERSPACE &&
+NlAttrIsLast(a, rem)) {
+return OvsOutputUserspaceAction(ovsFwdCtx, key, a);
+}
+
+newNbl = OvsPartialCopyNBL(ovsFwdCtx->switchContext, ovsFwdCtx->curNbl,
+   0, 0, TRUE /*copy NBL info*/);
+if (newNbl == NULL) {
+/*
+ * Skip the sample action when out of memory, but continue on with the
+ * rest of the action list.
+ */
+ovsActionStats.noCopiedNbl++;
+return STATUS_SUCCESS;
+}
+
+if (!OvsAddDeferredActions(newNbl, key, a)) {
+OVS_LOG_INFO(
+"Deferred actions limit reached, dropping sample action.");
+OvsCompleteNBL(ovsFwdCtx->switchContext, newNbl, TRUE);
+}
+
+return STATUS_SUCCESS;
 }
 
 /*
@@ -1838,43 +1963,15 @@ OvsDoExecute

Re: [ovs-dev] [PATCH] datapath-windows: Sample action support.

[Sorin Vinturis]

Nithin, as Alin said the userspace expects just the payload. I saw that in 
daemon logs while testing the patch. Below the logs that caught my attention 
and motivates the change.

"...
2016-06-01T15:04:07.307Z|00040|dpif(handler14)|DBG|system@ovs-system: action 
upcall:
recirc_id(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),eth(src=00:15:5d:79:85:06,dst=33:33:ff:00:01:84),in_port(6),eth_type(0x86dd),ipv6(src=1999::183,dst=ff02::1:ff00:184,label=0,proto=58,tclass=0,hlimit=255,frag=no),icmpv6(type=135,code=0),nd(target=::,sll=00:00:00:00:00:00,tll=00:00:00:00:00:00)
icmp6,dl_vlan=900,dl_vlan_pcp=0,dl_src=00:15:5d:79:85:06,dl_dst=33:33:ff:00:01:84,ipv6_src=1999::183,ipv6_dst=ff02::1:ff00:184,ipv6_label=0x0,nw_tos=0,nw_ecn=0,nw_ttl=255,icmp_type=135,icmp_code=0,nd_target=1999::184,nd_sll=00:15:5d:79:85:06,nd_tll=00:00:00:00:00:00
 icmp6_csum:5f4d
2016-06-01T15:04:07.308Z|00041|ofproto_dpif_upcall(handler14)|WARN|action 
upcall cookie has unexpected size 20
2016-06-01T15:04:07.433Z|00042|netlink_socket(handler14)|DBG|nl_sock_recv__ 
(Success): nl(len:392, type=19(ovs_packet), flags=0, seq=0, 
pid=3,genl(cmd=1,version=1)
2016-06-01T15:04:07.435Z|00043|dpif(handler14)|DBG|system@ovs-system: miss 
upcall:
recirc_id(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),eth(src=00:50:56:c0:00:01,dst=ff:ff:ff:ff:ff:ff),in_port(4),eth_type(0x0800),ipv4(src=192.168.159.1,dst=192.168.159.255,proto=17,tos=0,ttl=128,frag=no),udp(src=138,dst=138)
udp,vlan_tci=0x,dl_src=00:50:56:c0:00:01,dl_dst=ff:ff:ff:ff:ff:ff,nw_src=192.168.159.1,nw_dst=192.168.159.255,nw_tos=0,nw_ecn=0,nw_ttl=128,tp_src=138,tp_dst=138
 udp_csum:3c58
2016-06-01T15:04:07.437Z|00044|dpif(handler14)|DBG|system@ovs-system: get_stats 
success
..."

As the log shows the userdata length is 20, which is 4 bytes larger then the 
expected size (sizeof cookie = 16).
The line that generates the error is: 
https://github.com/openvswitch/ovs/blob/master/ofproto/ofproto-dpif-upcall.c#L956

-Sorin

-Original Message-
From: Alin Serdean 
Sent: Thursday, 26 May, 2016 12:20
To: Nithin Raju; Sorin Vinturis; dev@openvswitch.org
Subject: RE: [ovs-dev] [PATCH] datapath-windows: Sample action support.

Beside moving the new functions from Random.h to Util.h, LGTM.

> >+
> >+elem = OvsCreateQueueNlPacket(NlAttrData(userdataAttr),
> >+  NlAttrGetSize(userdataAttr),
> 
> The existing code passes ŒuserdataAttr¹ as-is and not the payload.
> Basically, it passes the NL_ATTR structure and not just the payload. 
> Any reason to strip off the header?
[Alin Gabriel Serdean: ] You get the header twice in the userspace hence the 
bad length we need just the payload when passing the userdata.
We could leave it as is or change the way we put the attribute in 
OvsCreateQueueNlPacket.
> 
> If you follow through to how OvsCreateQueueNlPacket() uses this, 
> you¹ll end up with NlMsgPutTailUnspec() and that needs the NL_ATTR 
> header to be present as part of the data.
> 
Thanks,
Alin.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] --with-dpdk configure option issue

[Bodireddy, Bhanuprakash]

>-Original Message-
>From: Mauricio Vásquez [mailto:mauriciovasquezber...@gmail.com]
>Sent: Wednesday, June 1, 2016 4:28 PM
>To: Bodireddy, Bhanuprakash 
>Cc: ovs dev 
>Subject: Re: --with-dpdk configure option issue
>
>
>
>On Wed, Jun 1, 2016 at 5:14 PM, Bodireddy, Bhanuprakash
> wrote:
>>-Original Message-
>>From: Mauricio Vásquez [mailto:mauriciovasquezber...@gmail.com]
>>Sent: Wednesday, June 1, 2016 3:37 PM
>>To: Bodireddy, Bhanuprakash 
>>Cc: ovs dev 
>>Subject: Re: --with-dpdk configure option issue
>>
>>
>>
>>On Wed, Jun 1, 2016 at 3:29 PM, Bodireddy, Bhanuprakash
>> wrote:
>>>-Original Message-
>>>From: Mauricio Vásquez [mailto:mauriciovasquezber...@gmail.com]
>>>Sent: Wednesday, June 1, 2016 11:17 AM
>>>To: ovs dev 
>>>Cc: Bodireddy, Bhanuprakash 
>>>Subject: --with-dpdk configure option issue
>>>
>>>Dear All,
>>>I noticed that when I run the command
>>>./configure --with-dpdk=$SOME_NON_EXISTING_ENV_VAR
>>>it does not give me an error, somewhere it says:
>>>"checking whether dpdk datapath is enabled... no" but there is not an
>>explicit
>>>error.
>>>I think this behavior should be avoided, an explicit error should be printed
>to
>>>avoid any possible confusion, as for example when DPDK_BUILD is not set.
>>
>>Thanks for reporting this issue.  This is treated more a misconfiguration than
>a
>>bug. Please see below.
>>The configure script was modified to handle auto discovery of DPDK library if
>>present in standard search paths with ' ./configure --with-dpdk' option.
>>It also handles other valid options as listed below in case (a),(b),(c), (e). 
>>All
>the
>>below options will set string 'with_dpdk' in OVS_CHECK_DPDK function in
>>acinclude.m4.
>>
>>(a)  ./configure --with-dpdk=$DPDK_BUILD                       [ $with_dpdk 
>>will be a
>>valid $DPDK_BUILD dir]
>>(b)  ./configure --with-dpdk=$DPDK_BUILD/install         [ $with_dpdk will be 
>>a
>>valid $DPDK_BUILD/install dir]
>>(c)   ./configure --without-dpdk.                                             
>> [$with_dpdk will be
>>'no']
>>(d)  ./configure --with-dpdk=""                                               
>> [$with_dpdk will be
>an
>>empty string]
>>(e)  ./configure                                                              
>>                  [ $with_dpdk will be
>an
>>empty string]
>>
>>In case (d), when empty string is passed to --with-dpdk option, it's not
>known
>>if user has invoked case (d) or case (e).  Hence I throw dpdk datapath isn't
>>enabled as part of configuration.
>>i.e "checking whether dpdk datapath is enabled... no".
>>
>>I had a look at the autotools documentation and I think there is a way to
>>distinguish between cases (d) and (e).
>>What do you think about something like this?
>>
>>diff --git a/acinclude.m4 b/acinclude.m4
>>index f3de855..9314d82 100644
>>--- a/acinclude.m4
>>+++ b/acinclude.m4
>>@@ -161,10 +161,11 @@ dnl Configure DPDK source tree
>> AC_DEFUN([OVS_CHECK_DPDK], [
>>   AC_ARG_WITH([dpdk],
>>   [AC_HELP_STRING([--with-dpdk=/path/to/dpdk],
>>-  [Specify the DPDK build directory])])
>>+  [Specify the DPDK build directory])],
>>+   [have_dpdk=true])
>>
>>   AC_MSG_CHECKING([whether dpdk datapath is enabled])
>>-  if test -z "$with_dpdk" || test "$with_dpdk" = no; then
>>+  if test "$have_dpdk" != true; then
>> AC_MSG_RESULT([no])
>> DPDKLIB_FOUND=false
>>   else
>This looks fine, but for one minor issue when using ./configure --without-dpdk
>option.
>Below it says dpdk datapath is still enabled and errors out..
>
>checking whether dpdk datapath is enabled... yes
>checking for no/include/rte_config.h... no
>checking for no/include/dpdk/rte_config.h... no
>configure: error: Could not find DPDK libraries in no/lib
>
>You are right!, what about?

Perfect! , Infact I was about to send the patch with the same tweak.
You can submit this patch, I will ack it.

>diff --git a/acinclude.m4 b/acinclude.m4
>index f3de855..a5080ef 100644
>--- a/acinclude.m4
>+++ b/acinclude.m4
>@@ -161,10 +161,11 @@ dnl Configure DPDK source tree
> AC_DEFUN([OVS_CHECK_DPDK], [
>   AC_ARG_WITH([dpdk],
>   [AC_HELP_STRING([--with-dpdk=/path/to/dpdk],
>-  [Specify the DPDK build directory])])
>+  [Specify the DPDK build directory])],
>+   [have_dpdk=true])
>
>   AC_MSG_CHECKING([whether dpdk datapath is enabled])
>-  if test -z "$with_dpdk" || test "$with_dpdk" = no; then
>+  if test "$have_dpdk" != true || test "$with_dpdk" = no; then
> AC_MSG_RESULT([no])
> DPDKLIB_FOUND=false
>   else
>
>I don’t think anyone would use '--without-dpdk' explicitly to avoid building
>DPDK datapath with OVS.
>
>Regards,
>Bhanu Prakash.
>
>>
>>>
>>>Bhanuprakash, I CC'ed you because you are author of 40b5ea86319f
>>>("acinclude: Autodetect DPDK location when configuring OVS"), then I think
>>>you know how  to fix it.
>>>Mauricio V,
>Regards,
>Mauricio V,

Re: [ovs-dev] --with-dpdk configure option issue

[Mauricio Vásquez]

On Wed, Jun 1, 2016 at 5:14 PM, Bodireddy, Bhanuprakash <
bhanuprakash.bodire...@intel.com> wrote:

> >-Original Message-
> >From: Mauricio Vásquez [mailto:mauriciovasquezber...@gmail.com]
> >Sent: Wednesday, June 1, 2016 3:37 PM
> >To: Bodireddy, Bhanuprakash 
> >Cc: ovs dev 
> >Subject: Re: --with-dpdk configure option issue
> >
> >
> >
> >On Wed, Jun 1, 2016 at 3:29 PM, Bodireddy, Bhanuprakash
> > wrote:
> >>-Original Message-
> >>From: Mauricio Vásquez [mailto:mauriciovasquezber...@gmail.com]
> >>Sent: Wednesday, June 1, 2016 11:17 AM
> >>To: ovs dev 
> >>Cc: Bodireddy, Bhanuprakash 
> >>Subject: --with-dpdk configure option issue
> >>
> >>Dear All,
> >>I noticed that when I run the command
> >>./configure --with-dpdk=$SOME_NON_EXISTING_ENV_VAR
> >>it does not give me an error, somewhere it says:
> >>"checking whether dpdk datapath is enabled... no" but there is not an
> >explicit
> >>error.
> >>I think this behavior should be avoided, an explicit error should be
> printed to
> >>avoid any possible confusion, as for example when DPDK_BUILD is not set.
> >
> >Thanks for reporting this issue.  This is treated more a misconfiguration
> than a
> >bug. Please see below.
> >The configure script was modified to handle auto discovery of DPDK
> library if
> >present in standard search paths with ' ./configure --with-dpdk' option.
> >It also handles other valid options as listed below in case (a),(b),(c),
> (e). All the
> >below options will set string 'with_dpdk' in OVS_CHECK_DPDK function in
> >acinclude.m4.
> >
> >(a)  ./configure --with-dpdk=$DPDK_BUILD   [
> $with_dpdk will be a
> >valid $DPDK_BUILD dir]
> >(b)  ./configure --with-dpdk=$DPDK_BUILD/install [ $with_dpdk
> will be a
> >valid $DPDK_BUILD/install dir]
> >(c)   ./configure --without-dpdk.
>   [$with_dpdk will be
> >'no']
> >(d)  ./configure --with-dpdk=""
>   [$with_dpdk will be an
> >empty string]
> >(e)  ./configure
>   [ $with_dpdk will be an
> >empty string]
> >
> >In case (d), when empty string is passed to --with-dpdk option, it's not
> known
> >if user has invoked case (d) or case (e).  Hence I throw dpdk datapath
> isn't
> >enabled as part of configuration.
> >i.e "checking whether dpdk datapath is enabled... no".
> >
> >I had a look at the autotools documentation and I think there is a way to
> >distinguish between cases (d) and (e).
> >What do you think about something like this?
> >
> >diff --git a/acinclude.m4 b/acinclude.m4
> >index f3de855..9314d82 100644
> >--- a/acinclude.m4
> >+++ b/acinclude.m4
> >@@ -161,10 +161,11 @@ dnl Configure DPDK source tree
> > AC_DEFUN([OVS_CHECK_DPDK], [
> >   AC_ARG_WITH([dpdk],
> >   [AC_HELP_STRING([--with-dpdk=/path/to/dpdk],
> >-  [Specify the DPDK build directory])])
> >+  [Specify the DPDK build directory])],
> >+   [have_dpdk=true])
> >
> >   AC_MSG_CHECKING([whether dpdk datapath is enabled])
> >-  if test -z "$with_dpdk" || test "$with_dpdk" = no; then
> >+  if test "$have_dpdk" != true; then
> > AC_MSG_RESULT([no])
> > DPDKLIB_FOUND=false
> >   else
>
> This looks fine, but for one minor issue when using ./configure
> --without-dpdk option.
> Below it says dpdk datapath is still enabled and errors out..
>
> checking whether dpdk datapath is enabled... yes
> checking for no/include/rte_config.h... no
> checking for no/include/dpdk/rte_config.h... no
> configure: error: Could not find DPDK libraries in no/lib
>
>
You are right!, what about?
diff --git a/acinclude.m4 b/acinclude.m4
index f3de855..a5080ef 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -161,10 +161,11 @@ dnl Configure DPDK source tree
 AC_DEFUN([OVS_CHECK_DPDK], [
   AC_ARG_WITH([dpdk],
   [AC_HELP_STRING([--with-dpdk=/path/to/dpdk],
-  [Specify the DPDK build directory])])
+  [Specify the DPDK build directory])],
+   [have_dpdk=true])

   AC_MSG_CHECKING([whether dpdk datapath is enabled])
-  if test -z "$with_dpdk" || test "$with_dpdk" = no; then
+  if test "$have_dpdk" != true || test "$with_dpdk" = no; then
 AC_MSG_RESULT([no])
 DPDKLIB_FOUND=false
   else


> I don’t think anyone would use '--without-dpdk' explicitly to avoid
> building DPDK datapath with OVS.
>
> Regards,
> Bhanu Prakash.
>
> >
> >>
> >>Bhanuprakash, I CC'ed you because you are author of 40b5ea86319f
> >>("acinclude: Autodetect DPDK location when configuring OVS"), then I
> think
> >>you know how  to fix it.
> >>Mauricio V,
>
> Regards,
Mauricio V,
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] --with-dpdk configure option issue

[Bodireddy, Bhanuprakash]

>-Original Message-
>From: Mauricio Vásquez [mailto:mauriciovasquezber...@gmail.com]
>Sent: Wednesday, June 1, 2016 3:37 PM
>To: Bodireddy, Bhanuprakash 
>Cc: ovs dev 
>Subject: Re: --with-dpdk configure option issue
>
>
>
>On Wed, Jun 1, 2016 at 3:29 PM, Bodireddy, Bhanuprakash
> wrote:
>>-Original Message-
>>From: Mauricio Vásquez [mailto:mauriciovasquezber...@gmail.com]
>>Sent: Wednesday, June 1, 2016 11:17 AM
>>To: ovs dev 
>>Cc: Bodireddy, Bhanuprakash 
>>Subject: --with-dpdk configure option issue
>>
>>Dear All,
>>I noticed that when I run the command
>>./configure --with-dpdk=$SOME_NON_EXISTING_ENV_VAR
>>it does not give me an error, somewhere it says:
>>"checking whether dpdk datapath is enabled... no" but there is not an
>explicit
>>error.
>>I think this behavior should be avoided, an explicit error should be printed 
>>to
>>avoid any possible confusion, as for example when DPDK_BUILD is not set.
>
>Thanks for reporting this issue.  This is treated more a misconfiguration than 
>a
>bug. Please see below.
>The configure script was modified to handle auto discovery of DPDK library if
>present in standard search paths with ' ./configure --with-dpdk' option.
>It also handles other valid options as listed below in case (a),(b),(c), (e). 
>All the
>below options will set string 'with_dpdk' in OVS_CHECK_DPDK function in
>acinclude.m4.
>
>(a)  ./configure --with-dpdk=$DPDK_BUILD                       [ $with_dpdk 
>will be a
>valid $DPDK_BUILD dir]
>(b)  ./configure --with-dpdk=$DPDK_BUILD/install         [ $with_dpdk will be a
>valid $DPDK_BUILD/install dir]
>(c)   ./configure --without-dpdk.                                              
>[$with_dpdk will be
>'no']
>(d)  ./configure --with-dpdk=""                                                
>[$with_dpdk will be an
>empty string]
>(e)  ./configure                                                               
>                 [ $with_dpdk will be an
>empty string]
>
>In case (d), when empty string is passed to --with-dpdk option, it's not known
>if user has invoked case (d) or case (e).  Hence I throw dpdk datapath isn't
>enabled as part of configuration.
>i.e "checking whether dpdk datapath is enabled... no".
>
>I had a look at the autotools documentation and I think there is a way to
>distinguish between cases (d) and (e).
>What do you think about something like this?
>
>diff --git a/acinclude.m4 b/acinclude.m4
>index f3de855..9314d82 100644
>--- a/acinclude.m4
>+++ b/acinclude.m4
>@@ -161,10 +161,11 @@ dnl Configure DPDK source tree
> AC_DEFUN([OVS_CHECK_DPDK], [
>   AC_ARG_WITH([dpdk],
>   [AC_HELP_STRING([--with-dpdk=/path/to/dpdk],
>-  [Specify the DPDK build directory])])
>+  [Specify the DPDK build directory])],
>+   [have_dpdk=true])
>
>   AC_MSG_CHECKING([whether dpdk datapath is enabled])
>-  if test -z "$with_dpdk" || test "$with_dpdk" = no; then
>+  if test "$have_dpdk" != true; then
> AC_MSG_RESULT([no])
> DPDKLIB_FOUND=false
>   else

This looks fine, but for one minor issue when using ./configure --without-dpdk 
option.
Below it says dpdk datapath is still enabled and errors out..

checking whether dpdk datapath is enabled... yes
checking for no/include/rte_config.h... no
checking for no/include/dpdk/rte_config.h... no
configure: error: Could not find DPDK libraries in no/lib

I don’t think anyone would use '--without-dpdk' explicitly to avoid building 
DPDK datapath with OVS.

Regards,
Bhanu Prakash.

>
>>
>>Bhanuprakash, I CC'ed you because you are author of 40b5ea86319f
>>("acinclude: Autodetect DPDK location when configuring OVS"), then I think
>>you know how  to fix it.
>>Mauricio V,

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

Re: [ovs-dev] --with-dpdk configure option issue

[Ben Pfaff]

On Wed, Jun 01, 2016 at 04:37:24PM +0200, Mauricio Vásquez wrote:
> On Wed, Jun 1, 2016 at 3:29 PM, Bodireddy, Bhanuprakash <
> bhanuprakash.bodire...@intel.com> wrote:
> 
> > >-Original Message-
> > >From: Mauricio Vásquez [mailto:mauriciovasquezber...@gmail.com]
> > >Sent: Wednesday, June 1, 2016 11:17 AM
> > >To: ovs dev 
> > >Cc: Bodireddy, Bhanuprakash 
> > >Subject: --with-dpdk configure option issue
> > >
> > >Dear All,
> > >I noticed that when I run the command
> > >./configure --with-dpdk=$SOME_NON_EXISTING_ENV_VAR
> > >it does not give me an error, somewhere it says:
> > >"checking whether dpdk datapath is enabled... no" but there is not an
> > explicit
> > >error.
> > >I think this behavior should be avoided, an explicit error should be
> > printed to
> > >avoid any possible confusion, as for example when DPDK_BUILD is not set.
> >
> > Thanks for reporting this issue.  This is treated more a misconfiguration
> > than a bug. Please see below.
> > The configure script was modified to handle auto discovery of DPDK library
> > if present in standard search paths with ' ./configure --with-dpdk' option.
> > It also handles other valid options as listed below in case (a),(b),(c),
> > (e). All the below options will set string 'with_dpdk' in OVS_CHECK_DPDK
> > function in acinclude.m4.
> >
> > (a)  ./configure --with-dpdk=$DPDK_BUILD   [
> > $with_dpdk will be a valid $DPDK_BUILD dir]
> > (b)  ./configure --with-dpdk=$DPDK_BUILD/install [ $with_dpdk will
> > be a valid $DPDK_BUILD/install dir]
> > (c)   ./configure --without-dpdk.
> > [$with_dpdk will be 'no']
> > (d)  ./configure --with-dpdk=""
> > [$with_dpdk will be an empty string]
> > (e)  ./configure
> >   [ $with_dpdk will be an empty string]
> >
> > In case (d), when empty string is passed to --with-dpdk option, it's not
> > known if user has invoked case (d) or case (e).  Hence I throw dpdk
> > datapath isn't enabled as part of configuration.
> > i.e "checking whether dpdk datapath is enabled... no".
> >
> 
> I had a look at the autotools documentation and I think there is a way to
> distinguish between cases (d) and (e).
> 
> What do you think about something like this?

Please go ahead and formally submit it.  It's best to fix this.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] --with-dpdk configure option issue

[Mauricio Vásquez]

On Wed, Jun 1, 2016 at 3:29 PM, Bodireddy, Bhanuprakash <
bhanuprakash.bodire...@intel.com> wrote:

> >-Original Message-
> >From: Mauricio Vásquez [mailto:mauriciovasquezber...@gmail.com]
> >Sent: Wednesday, June 1, 2016 11:17 AM
> >To: ovs dev 
> >Cc: Bodireddy, Bhanuprakash 
> >Subject: --with-dpdk configure option issue
> >
> >Dear All,
> >I noticed that when I run the command
> >./configure --with-dpdk=$SOME_NON_EXISTING_ENV_VAR
> >it does not give me an error, somewhere it says:
> >"checking whether dpdk datapath is enabled... no" but there is not an
> explicit
> >error.
> >I think this behavior should be avoided, an explicit error should be
> printed to
> >avoid any possible confusion, as for example when DPDK_BUILD is not set.
>
> Thanks for reporting this issue.  This is treated more a misconfiguration
> than a bug. Please see below.
> The configure script was modified to handle auto discovery of DPDK library
> if present in standard search paths with ' ./configure --with-dpdk' option.
> It also handles other valid options as listed below in case (a),(b),(c),
> (e). All the below options will set string 'with_dpdk' in OVS_CHECK_DPDK
> function in acinclude.m4.
>
> (a)  ./configure --with-dpdk=$DPDK_BUILD   [
> $with_dpdk will be a valid $DPDK_BUILD dir]
> (b)  ./configure --with-dpdk=$DPDK_BUILD/install [ $with_dpdk will
> be a valid $DPDK_BUILD/install dir]
> (c)   ./configure --without-dpdk.
> [$with_dpdk will be 'no']
> (d)  ./configure --with-dpdk=""
> [$with_dpdk will be an empty string]
> (e)  ./configure
>   [ $with_dpdk will be an empty string]
>
> In case (d), when empty string is passed to --with-dpdk option, it's not
> known if user has invoked case (d) or case (e).  Hence I throw dpdk
> datapath isn't enabled as part of configuration.
> i.e "checking whether dpdk datapath is enabled... no".
>

I had a look at the autotools documentation and I think there is a way to
distinguish between cases (d) and (e).

What do you think about something like this?

diff --git a/acinclude.m4 b/acinclude.m4
index f3de855..9314d82 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -161,10 +161,11 @@ dnl Configure DPDK source tree
 AC_DEFUN([OVS_CHECK_DPDK], [
   AC_ARG_WITH([dpdk],
   [AC_HELP_STRING([--with-dpdk=/path/to/dpdk],
-  [Specify the DPDK build directory])])
+  [Specify the DPDK build directory])],
+   [have_dpdk=true])

   AC_MSG_CHECKING([whether dpdk datapath is enabled])
-  if test -z "$with_dpdk" || test "$with_dpdk" = no; then
+  if test "$have_dpdk" != true; then
 AC_MSG_RESULT([no])
 DPDKLIB_FOUND=false
   else


> >
> >Bhanuprakash, I CC'ed you because you are author of 40b5ea86319f
> >("acinclude: Autodetect DPDK location when configuring OVS"), then I think
> >you know how  to fix it.
> >Mauricio V,
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Mega and Microflow caching

[Adonis Congaro]

Hi Antonio

Thanks a lot. That's what i'm looking for. But I also would like to
understand the ovs cache in the kernel as well. Can you point out?

Anyway, okay, got it. Sorry for the wrong thread.
Ado

On Wed, Jun 1, 2016 at 6:39 PM, Fischetti, Antonio <
antonio.fische...@intel.com> wrote:

> Hi Ado,
> are you're referring to OVS in userspace?
> If that's the case, have a look in lib/dpif-netdev.c.
>
> You can start from dp_netdev_process_rxq_port() which receives
> the packets. All functions like emc_*() refer to the Microflows
> while those as dpcls_*() are for the Megaflow management.
>
> BTW, for questions like this it's better to post into OVS-Discuss
> mailing-list. This ovs-dev is mainly for patch submissions, code
> review or similar.
>
> Antonio
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Adonis
> > Congaro
> > Sent: Wednesday, June 1, 2016 6:24 AM
> > To: dev@openvswitch.org
> > Subject: [ovs-dev] Mega and Microflow caching
> >
> > Hi
> > I am trying to understand the Mega and Microflow caching. I already
> > understand the concept of it, but I would like to see how it works in
> > code
> > level.
> >
> > Can someone suggest me which file or function in the source code to
> > look at
> > in order to understand the code flow of Micro/Mega flow caching?
> >
> > Thanks in advance,
> > Ado
> > ___
> > 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] OVS is failing while starting with DPDK

[Bodireddy, Bhanuprakash]

>-Original Message-
>From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Sheroo
>Pratap
>Sent: Wednesday, June 1, 2016 9:48 AM
>To: ovs dev 
>Subject: [ovs-dev] OVS is failing while starting with DPDK
>
>Hi All,
>
>  I am trying to start OVS with DPDK but it is failing with below error.
>
>root@osboxes:/home/osboxes/ovs# ovs-vswitchd unix:$DB_SOCK --pidfile --
>detach 2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores
>on NUMA node 0 2016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1
>NUMA nodes and 1 CPU cores
>2016-06-
>01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/d
>b.sock:
>connecting...
>2016-06-
>01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/d
>b.sock:
>connected
>*2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not supported in this copy of
>Open vSwitch.* root@osboxes:/home/osboxes/ovs#
>
>Below is the steps is have followed so far.
>
>1) My OVS version is master ovs i.e. 2.5.90, ubuntu 15.10 and kernel version is
>4.6
>2) DPDK version is 16.04  (as recommended in INSTALL.DPDK.md of master
>ovs)
>3) Following are the steps as have executed as mentioned in
>INSTALL.DPDK.md
>1)  export DPDK_DIR=/usr/src/dpdk-16.04
>2)  cd $DPDK_DIR
>3) make install T=x86_64-native-linuxapp-gcc DESTDIR=install
>4) export DPDK_BUILD=$DPDK_DIR/x86_64-native-linuxapp-gcc/
>5) cd $(OVS_DIR)/
>   6) ./boot.sh
>   7) ./configure --with-dpdk=$DPDK_BUILD CFLAGS="-g -O2 -Wno-cast-
>align"
>   8) make CFLAGS='-O3 -march=native
>   9)  added below line in /etc/default/grub
>   default_hugepagesz=1GB hugepagesz=1G hugepages=1
>  Snapshot of grub
> GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash
>default_hugepagesz=1GB hugepagesz=1G hugepages=1"
> GRUB_CMDLINE_LINUX=""
> 10) modprobe uio
> 11) insmod $DPDK_BUILD/kmod/igb_uio.ko
> 12) $DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio eth0
> 13) mount -t hugetlbfs -o pagesize=2MB none /dev/hugepages
> 14) mkdir -p /usr/local/etc/openvswitch
> 15) mkdir -p /usr/local/var/run/openvswitch
> 16) rm /usr/local/etc/openvswitch/conf.db
> 17) ovsdb-tool create /usr/local/etc/openvswitch/conf.db  \
> /usr/local/share/openvswitch/vswitch.ovsschema
>
> 18) removed SSL certificates while configuraing ovsdb :
>  ovsdb-server
>--remote=punix:/usr/local/var/run/openvswitch/db.sock
>--remote=db:Open_vSwitch,Open_vSwitch,manager_options  --pidfile --
>detach
> 19) ovs-vsctl --no-wait init
> 20) export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
> 21) ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
>
>
>
>
>
>
>
>* 22) faling here : ovs-vswitchd unix:$DB_SOCK --pidfile
>--detachroot@osboxes:/home/osboxes/ovs# ovs-vswitchd
>unix:$DB_SOCK --pidfile --detach
>2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on
>NUMA
>node 02016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1
>NUMA nodes and 1 CPU cores
>2016-06-
>01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/d
>b.sock:
>connecting...
>2016-06-
>01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/d
>b.sock:
>connected2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not supported
>in this copy of Open vSwitch.*

This is more likely OVS configuration issue and check the 'DPDK_BUILD' env 
variable if it is set appropriately. 
Check this thread for more information: 
http://openvswitch.org/pipermail/dev/2016-June/071955.html

>
>Please anyone can help, after executing step 22 getting error "DPDK not
>supported in this copy of Open vSwitch"
>
>Thanks and Regards
> S Pratap
>___
>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] --with-dpdk configure option issue

[Bodireddy, Bhanuprakash]

>-Original Message-
>From: Mauricio Vásquez [mailto:mauriciovasquezber...@gmail.com]
>Sent: Wednesday, June 1, 2016 11:17 AM
>To: ovs dev 
>Cc: Bodireddy, Bhanuprakash 
>Subject: --with-dpdk configure option issue
>
>Dear All,
>I noticed that when I run the command
>./configure --with-dpdk=$SOME_NON_EXISTING_ENV_VAR
>it does not give me an error, somewhere it says:
>"checking whether dpdk datapath is enabled... no" but there is not an explicit
>error.
>I think this behavior should be avoided, an explicit error should be printed to
>avoid any possible confusion, as for example when DPDK_BUILD is not set.

Thanks for reporting this issue.  This is treated more a misconfiguration than 
a bug. Please see below.
The configure script was modified to handle auto discovery of DPDK library if 
present in standard search paths with ' ./configure --with-dpdk' option.
It also handles other valid options as listed below in case (a),(b),(c), (e). 
All the below options will set string 'with_dpdk' in OVS_CHECK_DPDK function in 
acinclude.m4.

(a)  ./configure --with-dpdk=$DPDK_BUILD   [ $with_dpdk 
will be a valid $DPDK_BUILD dir]
(b)  ./configure --with-dpdk=$DPDK_BUILD/install [ $with_dpdk will be a 
valid $DPDK_BUILD/install dir]
(c)   ./configure --without-dpdk.  
[$with_dpdk will be 'no']
(d)  ./configure --with-dpdk=""
[$with_dpdk will be an empty string]
(e)  ./configure
[ $with_dpdk will be an empty string]

In case (d), when empty string is passed to --with-dpdk option, it's not known 
if user has invoked case (d) or case (e).  Hence I throw dpdk datapath isn't 
enabled as part of configuration.
i.e "checking whether dpdk datapath is enabled... no".  

>
>Bhanuprakash, I CC'ed you because you are author of 40b5ea86319f
>("acinclude: Autodetect DPDK location when configuring OVS"), then I think
>you know how  to fix it.
>Mauricio V,
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Removing a flow with a new field

[Amrane Ait Zeouay]

Hi,
I added a new field to the rules like the field "priority" and when i want
to delete a flow with "ovs-ofctl del-flows br0 new_field=80" or with
--strict the ovs doesn't do anything, and even i wanted to delete a flow
with priority using -strict nothing happens to the rules.
so can anyone help me in this ?
Thank you.
Best regards.


*static char * WARN_UNUSED_RESULT*
*parse_ofp_str__(struct ofputil_flow_mod *fm, int command, char *string,*
*enum ofputil_protocol *usable_protocols)*
*{*
*enum {*
*F_OUT_PORT = 1 << 0,*
*F_ACTIONS = 1 << 1,*
*F_TIMEOUT = 1 << 3,*
*F_PRIORITY = 1 << 4,*
*F_FLAGS = 1 << 5,*
* F_NEW_FIELD = 1 << 6,*
*} fields;*
*char *save_ptr = NULL;*
*char *act_str = NULL;*
*char *name;*

**usable_protocols = OFPUTIL_P_ANY;*

*switch (command) {*
*case -1:*
*fields = F_OUT_PORT;*
*break;*

*case OFPFC_ADD:*
*fields = F_ACTIONS | F_TIMEOUT | F_PRIORITY | F_FLAGS
| F_NEW_FIELD;*
*break;*

*case OFPFC_DELETE:*
*fields = F_OUT_PORT | F_NEW_FIELD;*
*break;*

*case OFPFC_DELETE_STRICT:*
*fields = F_OUT_PORT | F_PRIORITY | F_NEW_FIELD;*
*break;*

*case OFPFC_MODIFY:*
*fields = F_ACTIONS | F_TIMEOUT | F_PRIORITY | F_FLAGS
| F_NEW_FIELD;*
*break;*

*case OFPFC_MODIFY_STRICT:*
*fields = F_ACTIONS | F_TIMEOUT | F_PRIORITY | F_FLAGS
| F_NEW_FIELD;*
*break;*

*default:*
*OVS_NOT_REACHED();*
*}*

-- 

Amrane Ait Zeouay

Engineer Student in The Development of Software and Systems

University of Western Brittany

Tel:  +33 7 62 25 56 03 <+33+7+62+25+56+03>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] [PATCH v1 1/2] ovn-controller: Add 'na' action inovn-controller

[Ryan Moats]

"dev"  wrote on 06/01/2016 02:18:13 AM:

> From: Zong Kai LI 
> To: dev@openvswitch.org
> Cc: Zong Kai LI 
> Date: 06/01/2016 02:19 AM
> Subject: [ovs-dev] [PATCH] [PATCH v1 1/2] ovn-controller: Add 'na'
> action in ovn-controller
> Sent by: "dev" 
>
> This patch adds a new OVN action 'na' to support ND versus ARP.
>
> When ovn-controller received a ND packet, it frames a NA packet for
> reply, with mac address parsed from userdata as eth.dst. Then it
> reloads metadata info from previous packet to framed packet, and
> finally send the framed packet back with left actions.
>
> Eg. na{12:34:56:78:9a:bc; outport = inport; inport = ""; output;};
>
> Since patch port for IPv6 router interface is not ready yet, this
> patch will only try to deal with ND from VM. This patch will set
> RSO flags to 011.
>
> The next patch will add logical flows for this action.
>
> Signed-off-by: Zong Kai LI 
> ---

I admit that I haven't crawled through the code, but a quick scan
doesn't show me any test additions here, and since I don't see
part 2 in the patch queue, I'm left wondering where they are.

Can you please re-spin with some tests of the new functionality
included in the patch set?

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

Re: [ovs-dev] [PATCH] lib/packets: Add compose_na

[Ryan Moats]

"dev"  wrote on 06/01/2016 01:13:03 AM:

> From: Zong Kai LI 
> To: dev@openvswitch.org
> Cc: Zong Kai LI 
> Date: 06/01/2016 01:13 AM
> Subject: [ovs-dev] [PATCH] lib/packets: Add compose_na
> Sent by: "dev" 
>
> Add a method compose_na to compose a NA packet.
> The ND feature of OVN will base on this.
>
> Signed-off-by: Zong Kai LI 

Since this is a fairly small change, and it is targeted at adding
the na action into ovn-controller, I think I'd be more comfortable
if this were combined with that change set.

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

Re: [ovs-dev] [PATCH] lib: Use a more accurate value for CPU count (sched_getaffinity).

[Ryan Moats]

"dev"  wrote on 06/01/2016 06:55:41 AM:

> From: Quentin Monnet 
> To: ovs-dev 
> Date: 06/01/2016 06:56 AM
> Subject: Re: [ovs-dev] [PATCH] lib: Use a more accurate value for
> CPU count (sched_getaffinity).
> Sent by: "dev" 
>
> Hi all,
>
> Does anyone have some feedback about this patch, please?
>
> Best regards,
> Quentin

[snip...]

> > @@ -614,9 +555,17 @@ count_cpu_cores(void)
> >
> >  if (ovsthread_once_start(&once)) {
> >  #ifndef _WIN32
> > -parse_cpuinfo(&n_cores);
> > -if (!n_cores) {
> > -n_cores = sysconf(_SC_NPROCESSORS_ONLN);
> > +n_cores = sysconf(_SC_NPROCESSORS_ONLN);
> > +if (n_cores > 0) {
> > +cpu_set_t *set = CPU_ALLOC(n_cores);
> > +
> > +if (set) {
> > +size_t size = CPU_ALLOC_SIZE(n_cores);
> > +
> > +if (!sched_getaffinity(0, size, set)) {
> > +n_cores = CPU_COUNT_S(size, set);
> > +}
> > +}
> >  }
> >  #else
> >  SYSTEM_INFO sysinfo;

It looks to me like there is a missing CPU_FREE(set)
call at the end of the new if block...

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

Re: [ovs-dev] [PATCH] lib: Use a more accurate value for CPU count (sched_getaffinity).

[Quentin Monnet]

Hi all,

Does anyone have some feedback about this patch, please?

Best regards,
Quentin


2016-05-20 (11:20 +0200) ~ Quentin Monnet
> From: David Marchand 
>
> Relying on /proc/cpuinfo to count the number of available cores is not
> the best option:
>
> - The code is x86-specific.
> - If the process is started with a different CPU affinity, then it will
>   wrongly try to start too many threads (for an example, imagine an OVS
>   daemon restricted to 4 CPU threads on a 128 threads system).
>
> This commit removes /proc/cpuinfo parsing, and introduces instead a call
> to sched_getaffinity(), which is architecture-independant, in order to
> retrieve the list of CPU threads available to the current process and to
> count them.
>
> Signed-off-by: David Marchand 
> Signed-off-by: Liu Xiaofeng 
> Signed-off-by: Quentin Monnet 
> ---
>  lib/ovs-thread.c | 75 
> +---
>  1 file changed, 12 insertions(+), 63 deletions(-)
>
> diff --git a/lib/ovs-thread.c b/lib/ovs-thread.c
> index 3c065cf15fb7..f084ed1f72ad 100644
> --- a/lib/ovs-thread.c
> +++ b/lib/ovs-thread.c
> @@ -545,67 +545,8 @@ ovs_thread_stats_next_bucket(const struct 
> ovsthread_stats *stats, size_t i)
>  }
>  
>  
> -/* Parses /proc/cpuinfo for the total number of physical cores on this system
> - * across all CPU packages, not counting hyper-threads.
> - *
> - * Sets *n_cores to the total number of cores on this system, or 0 if the
> +/* Returns the total number of cores available to this process, or 0 if the
>   * number cannot be determined. */
> -static void
> -parse_cpuinfo(long int *n_cores)
> -{
> -static const char file_name[] = "/proc/cpuinfo";
> -char line[128];
> -uint64_t cpu = 0; /* Support up to 64 CPU packages on a single system. */
> -long int cores = 0;
> -FILE *stream;
> -
> -stream = fopen(file_name, "r");
> -if (!stream) {
> -VLOG_DBG("%s: open failed (%s)", file_name, ovs_strerror(errno));
> -return;
> -}
> -
> -while (fgets(line, sizeof line, stream)) {
> -unsigned int id;
> -
> -/* Find the next CPU package. */
> -if (ovs_scan(line, "physical id%*[^:]: %u", &id)) {
> -if (id > 63) {
> -VLOG_WARN("Counted over 64 CPU packages on this system. "
> -  "Parsing %s for core count may be inaccurate.",
> -  file_name);
> -cores = 0;
> -break;
> -}
> -
> -if (cpu & (1ULL << id)) {
> -/* We've already counted this package's cores. */
> -continue;
> -}
> -cpu |= 1ULL << id;
> -
> -/* Find the number of cores for this package. */
> -while (fgets(line, sizeof line, stream)) {
> -int count;
> -
> -if (ovs_scan(line, "cpu cores%*[^:]: %u", &count)) {
> -cores += count;
> -break;
> -}
> -}
> -}
> -}
> -fclose(stream);
> -
> -*n_cores = cores;
> -}
> -
> -/* Returns the total number of cores on this system, or 0 if the number 
> cannot
> - * be determined.
> - *
> - * Tries not to count hyper-threads, but may be inaccurate - particularly on
> - * platforms that do not provide /proc/cpuinfo, but also if /proc/cpuinfo is
> - * formatted different to the layout that parse_cpuinfo() expects. */
>  int
>  count_cpu_cores(void)
>  {
> @@ -614,9 +555,17 @@ count_cpu_cores(void)
>  
>  if (ovsthread_once_start(&once)) {
>  #ifndef _WIN32
> -parse_cpuinfo(&n_cores);
> -if (!n_cores) {
> -n_cores = sysconf(_SC_NPROCESSORS_ONLN);
> +n_cores = sysconf(_SC_NPROCESSORS_ONLN);
> +if (n_cores > 0) {
> +cpu_set_t *set = CPU_ALLOC(n_cores);
> +
> +if (set) {
> +size_t size = CPU_ALLOC_SIZE(n_cores);
> +
> +if (!sched_getaffinity(0, size, set)) {
> +n_cores = CPU_COUNT_S(size, set);
> +}
> +}
>  }
>  #else
>  SYSTEM_INFO sysinfo;
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH V2 4/4] tests: Fix fail of OVS_APP_EXIT_AND_WAIT on Windows

[Paul Boca]

The problem is that on some cases it gets called with the socket
name instead of the service name.

Signed-off-by: Paul-Daniel Boca 
---
 tests/ovs-macros.at | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
index 470c31c..604b277 100644
--- a/tests/ovs-macros.at
+++ b/tests/ovs-macros.at
@@ -135,9 +135,14 @@ dnl
 dnl Ask the daemon named DAEMON to exit, via ovs-appctl, and then waits for it
 dnl to exit.
 m4_define([OVS_APP_EXIT_AND_WAIT],
-  [TMPPID=$(cat "$OVS_RUNDIR"/$1.pid 2>/dev/null)
+  [
+   if test "$IS_WIN32" = "no"; then
+ TMPPID=$(cat "$OVS_RUNDIR"/$1.pid 2>/dev/null)
+   fi
AT_CHECK([ovs-appctl -t $1 exit])
-   OVS_WAIT_WHILE([kill -0 $TMPPID 2>/dev/null])])
+   if test "$IS_WIN32" = "no"; then
+ OVS_WAIT_WHILE([kill -0 $TMPPID 2>/dev/null])
+   fi])
 
 dnl OVS_APP_EXIT_AND_WAIT_BY_TARGET(DAEMON)
 dnl
-- 
2.7.2.windows.1
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH V2 3/4] tests: Modified OVS_APP_EXIT_AND_WAIT_BY_TARGET to work on windows too

[Paul Boca]

On Windows the CTL file doesn't contain the PID in it's name

Signed-off-by: Paul-Daniel Boca 
---
 tests/ovs-macros.at | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
index e5710a0..470c31c 100644
--- a/tests/ovs-macros.at
+++ b/tests/ovs-macros.at
@@ -145,7 +145,11 @@ dnl Ask the daemon named DAEMON to exit, via ovs-appctl 
(using the target
 dnl argument), and then waits for it to exit.
 m4_define([OVS_APP_EXIT_AND_WAIT_BY_TARGET],
   [TMPPID=`cat "$OVS_RUNDIR"/$1.pid 2>/dev/null`
-   AT_CHECK([ovs-appctl --target=$OVS_RUNDIR/ovsdb-server.$TMPPID.ctl exit])
+   if test "$IS_WIN32" = "yes"; then
+AT_CHECK([ovs-appctl --target=$OVS_RUNDIR/ovsdb-server.ctl exit])
+   else
+ AT_CHECK([ovs-appctl --target=$OVS_RUNDIR/ovsdb-server.$TMPPID.ctl exit])
+   fi
OVS_WAIT_WHILE([kill -0 $TMPPID 2>/dev/null])])
 
 dnl on_exit "COMMAND"
-- 
2.7.2.windows.1
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH V2 2/4] ovs-ofctl: Fixed PID file naming on windows

[Paul Boca]

If the --pidfile option doesn't contain ":" then the PID file name is always 
ovs-ofctl.pid

Signed-off-by: Paul-Daniel Boca 
---
 lib/daemon-windows.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/daemon-windows.c b/lib/daemon-windows.c
index ac71aa1..8cf0fea 100644
--- a/lib/daemon-windows.c
+++ b/lib/daemon-windows.c
@@ -485,8 +485,12 @@ daemon_become_new_user(bool access_datapath OVS_UNUSED)
 char *
 make_pidfile_name(const char *name)
 {
-if (name && strchr(name, ':')) {
-return xstrdup(name);
+if (name) {
+if (strchr(name, ':')) {
+return xstrdup(name);
+} else {
+return xasprintf("%s/%s", ovs_rundir(), name);
+}
 } else {
 return xasprintf("%s/%s.pid", ovs_rundir(), program_name);
 }
-- 
2.7.2.windows.1
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH V2 1/4] tests: Fixed access denied on ovs-vswitchd.log

[Paul Boca]

On Windows trying to overwrite the opened ovs-vswitchd.log
fails with access denied. Closing it before trying to overwrite it
solves the problem

Signed-off-by: Paul-Daniel Boca 
---
 tests/ofproto-dpif.at | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index bf9cf88..f65d391 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -6923,7 +6923,11 @@ OVS_WAIT_UNTIL([grep "monitor thread created" 
ovs-vswitchd.log])
 AT_CHECK([ovs-vsctl set interface p0 bfd:enable=false])
 # check log.
 OVS_WAIT_UNTIL([grep "monitor thread terminated" ovs-vswitchd.log])
-AT_CHECK([sed -e '/^.*ofproto_dpif_monitor.*$/d' < ovs-vswitchd.log > tmp && 
mv tmp ovs-vswitchd.log && ovs-appctl vlog/reopen])
+if test "$IS_WIN32" = "no"; then
+  AT_CHECK([sed -e '/^.*ofproto_dpif_monitor.*$/d' < ovs-vswitchd.log > tmp && 
mv tmp ovs-vswitchd.log && ovs-appctl vlog/reopen])
+else
+  AT_CHECK([sed -e '/^.*ofproto_dpif_monitor.*$/d' < ovs-vswitchd.log > tmp && 
ovs-appctl.exe vlog/close && mv tmp ovs-vswitchd.log && ovs-appctl vlog/reopen])
+fi
 
 # enable cfm on p0.
 AT_CHECK([ovs-vsctl set interface p0 cfm_mpid=10])
@@ -6933,7 +6937,11 @@ OVS_WAIT_UNTIL([grep "monitor thread created" 
ovs-vswitchd.log])
 AT_CHECK([ovs-vsctl remove interface p0 cfm_mpid 10])
 # check log.
 OVS_WAIT_UNTIL([grep "monitor thread terminated" ovs-vswitchd.log])
-AT_CHECK([sed -e '/^.*ofproto_dpif_monitor.*$/d' < ovs-vswitchd.log > tmp && 
mv tmp ovs-vswitchd.log && ovs-appctl vlog/reopen])
+if test "$IS_WIN32" = "no"; then
+  AT_CHECK([sed -e '/^.*ofproto_dpif_monitor.*$/d' < ovs-vswitchd.log > tmp && 
mv tmp ovs-vswitchd.log && ovs-appctl vlog/reopen])
+else
+  AT_CHECK([sed -e '/^.*ofproto_dpif_monitor.*$/d' < ovs-vswitchd.log > tmp && 
ovs-appctl.exe vlog/close && mv tmp ovs-vswitchd.log && ovs-appctl vlog/reopen])
+fi
 
 # enable both bfd and cfm on p0.
 AT_CHECK([ovs-vsctl set interface p0 bfd:enable=true cfm_mpid=10])
-- 
2.7.2.windows.1
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Delivery reports about your e-mail

[MAILER-DAEMON]

The message could not be delivered

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

[ovs-dev] RETURNED MAIL: SEE TRANSCRIPT FOR DETAILS

[shiseitokyo]

Your message could not be delivered

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

[ovs-dev] --with-dpdk configure option issue

[Mauricio Vásquez]

Dear All,

I noticed that when I run the command
./configure --with-dpdk=$SOME_NON_EXISTING_ENV_VAR
it does not give me an error, somewhere it says:
"checking whether dpdk datapath is enabled... no" but there is not an
explicit error.

I think this behavior should be avoided, an explicit error should be
printed to avoid any possible confusion, as for example when DPDK_BUILD is
not set.

Bhanuprakash, I CC'ed you because you are author of 40b5ea86319f
("acinclude: Autodetect DPDK location when configuring OVS"), then I think
you know how  to fix it.

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

Re: [ovs-dev] OVS is failing while starting with DPDK

[Wojciechowicz, RobertX]

From: Mauricio Vásquez [mailto:mauricio.vasquezber...@studenti.polito.it]
Sent: Wednesday, June 1, 2016 11:47 AM
To: Wojciechowicz, RobertX 
Cc: Sheroo Pratap ; ovs dev 

Subject: Re: [ovs-dev] OVS is failing while starting with DPDK

Hi RobertX,

On Wed, Jun 1, 2016 at 11:26 AM, Wojciechowicz, RobertX 
mailto:robertx.wojciechow...@intel.com>> wrote:
Hi Sheroo,

my suggestions inline

> -Original Message-
> From: dev 
> [mailto:dev-boun...@openvswitch.org] On 
> Behalf Of Sheroo
> Pratap
> Sent: Wednesday, June 1, 2016 10:48 AM
> To: ovs dev mailto:dev@openvswitch.org>>
> Subject: [ovs-dev] OVS is failing while starting with DPDK
>
> Hi All,
>
>   I am trying to start OVS with DPDK but it is failing with below error.
>
> root@osboxes:/home/osboxes/ovs# ovs-vswitchd unix:$DB_SOCK --pidfile
> --detach
> 2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on
> NUMA
> node 0
> 2016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1 NUMA nodes
> and 1 CPU
> cores
> 2016-06-
> 01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> db.sock:
> connecting...
> 2016-06-
> 01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> db.sock:
> connected
> *2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not supported in this copy of
> Open vSwitch.*
> root@osboxes:/home/osboxes/ovs#
>
> Below is the steps is have followed so far.
>
> 1) My OVS version is master ovs i.e. 2.5.90, ubuntu 15.10 and kernel
> version is 4.6
> 2) DPDK version is 16.04  (as recommended in 
> INSTALL.DPDK.md of master
> ovs)
> 3) Following are the steps as have executed as mentioned in
> INSTALL.DPDK.md
> 1)  export DPDK_DIR=/usr/src/dpdk-16.04
> 2)  cd $DPDK_DIR
> 3) make install T=x86_64-native-linuxapp-gcc DESTDIR=install
> 4) export DPDK_BUILD=$DPDK_DIR/x86_64-native-linuxapp-gcc/
> 5) cd $(OVS_DIR)/
>6) ./boot.sh
>7) ./configure --with-dpdk=$DPDK_BUILD CFLAGS="-g -O2
> -Wno-cast-align"
>8) make CFLAGS='-O3 -march=native
>9)  added below line in /etc/default/grub
>default_hugepagesz=1GB hugepagesz=1G hugepages=1
>   Snapshot of grub
>  GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo
> Debian`
>  GRUB_CMDLINE_LINUX_DEFAULT="quiet splash
> default_hugepagesz=1GB hugepagesz=1G hugepages=1"
>  GRUB_CMDLINE_LINUX=""
>  10) modprobe uio
>  11) insmod $DPDK_BUILD/kmod/igb_uio.ko
>  12) $DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio eth0
>  13) mount -t hugetlbfs -o pagesize=2MB none /dev/hugepages
>  14) mkdir -p /usr/local/etc/openvswitch
>  15) mkdir -p /usr/local/var/run/openvswitch
>  16) rm /usr/local/etc/openvswitch/conf.db
>  17) ovsdb-tool create /usr/local/etc/openvswitch/conf.db  \
>  /usr/local/share/openvswitch/vswitch.ovsschema
>
>  18) removed SSL certificates while configuraing ovsdb :
>   ovsdb-server
> --remote=punix:/usr/local/var/run/openvswitch/db.sock
> --remote=db:Open_vSwitch,Open_vSwitch,manager_options  --pidfile --
> detach
[RW] Make sure that ovsdb server started successfully

>  19) ovs-vsctl --no-wait init
>  20) export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
>  21) ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true

[RW] Check in the database if dpdk-init value was written properly.
I saw situations where ovsdb server was not ready to work yet,
so writing to it was not possible. Waiting a few seconds before writing helped.

>
>
>
>
>
>
>
> * 22) faling here : ovs-vswitchd unix:$DB_SOCK --pidfile
> --detachroot@osboxes:/home/osboxes/ovs# ovs-vswitchd
> unix:$DB_SOCK --pidfile --detach
> 2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on
> NUMA
> node 02016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1
> NUMA nodes and 1 CPU cores
> 2016-06-
> 01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> db.sock:
> connecting...
> 2016-06-
> 01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> db.sock:
> connected2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not
> supported
> in this copy of Open vSwitch.*

[RW] This error message means that dpdk-init has not "true" value in db.

I am not pretty sure that the error message means that, according to my 
understanding it means that the dpdk-init is true but ovs was not built with 
DPDK support. You can look at the dpdk_init() function in lib/netdev-nodpdk.c, 
this is a stub used when there is not DPDK support.

[RW] Oh yes, you’re right. It seems that OVS is not built with DPDK support. 
Sorry for the confusion.


>
> Please anyone can help, after executing step 22 getting error "DPDK not
> supported in this copy of Open vSwitch"
>
> Thanks and Regards
>  S Pratap

Br,
Robert
___
dev mailing

Re: [ovs-dev] [PATCH] ovsdb: Expose vhost-user socket directory in ovsdb

[Wojciechowicz, RobertX]

Hi Aaron,

thank you for review.
I will address your suggestions and prepare the second version of this patch.

Br,
Robert

> -Original Message-
> From: Aaron Conole [mailto:acon...@redhat.com]
> Sent: Tuesday, May 31, 2016 8:32 PM
> To: Wojciechowicz, RobertX 
> Cc: dev@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH] ovsdb: Expose vhost-user socket directory in
> ovsdb
> 
> 
> Hi Robert,
> 
> Robert Wojciechowicz  writes:
> 
> > In order to correctly interoperate with Openstack and ODL,
> > the vhost-user socket directory must be exposed from OVS via OVSDB.
> > Different distros may package OVS in different ways,
> > so the locations of these sockets may vary depending on how
> > ovs-vswitchd has been started. Some clients need information where
> > the sockets are located when instantiating Qemu virtual machines.
> > The full vhost-user socket directory is constructed from current
> > OVS working directory and optionally from specified subdirectory.
> > This patch exposes vhost-user socket directory in Open_vSwitch
> > table in other_config column in two following keys:
> > 1. ovs-run-dir- OVS working directory
> > 2. vhost-sock-dir - subdirectory of ovs-run-dir (might be empty)
> >
> > Signed-off-by: Robert Wojciechowicz 
> 
> I think this idea makes sense.  Neutron plugin would want to know this
> sort of thing.  I don't know much about the thinking w.r.t. putting
> these kinds of values in database responses, but it seems to be a good
> place for interop with other projects.
> 
> Just some nits below.
> 
> > ---
> >  lib/netdev-dpdk.c| 38 ++
> >  lib/netdev-dpdk.h|  9 +
> >  vswitchd/bridge.c|  2 ++
> >  vswitchd/vswitch.xml | 11 +++
> >  4 files changed, 56 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> > index 9ffa7ff..4e68bd6 100644
> > --- a/lib/netdev-dpdk.c
> > +++ b/lib/netdev-dpdk.c
> > @@ -138,9 +138,13 @@ BUILD_ASSERT_DECL((MAX_NB_MBUF /
> ROUND_DOWN_POW2(MAX_NB_MBUF/MIN_NB_MBUF))
> >
> >  #ifdef VHOST_CUSE
> >  static char *cuse_dev_name = NULL;/* Character device
> cuse_dev_name. */
> > +#else
> > +static char *sock_dir_subcomponent = NULL;   /* Subdir of OVS run dir
> > +for vhost-user sockets */
> >  #endif
> >  static char *vhost_sock_dir = NULL;   /* Location of vhost-user sockets */
> >
> > +
> >  /*
> >   * Maximum amount of time in micro seconds to try and enqueue to vhost.
> >   */
> > @@ -3086,9 +3090,6 @@ dpdk_init__(const struct smap
> *ovs_other_config)
> >  bool auto_determine = true;
> >  int err = 0;
> >  cpu_set_t cpuset;
> > -#ifndef VHOST_CUSE
> > -char *sock_dir_subcomponent;
> > -#endif
> >
> >  if (!smap_get_bool(ovs_other_config, "dpdk-init", false)) {
> >  VLOG_INFO("DPDK Disabled - to change this requires a restart.\n");
> > @@ -3119,10 +3120,11 @@ dpdk_init__(const struct smap
> *ovs_other_config)
> >  VLOG_ERR("vhost-user sock directory request '%s/%s' has 
> > invalid"
> >   "characters '..' - using %s instead.",
> >   ovs_rundir(), sock_dir_subcomponent, ovs_rundir());
> > +sock_dir_subcomponent = "";
> >  }
> > -free(sock_dir_subcomponent);
> >  } else {
> >  vhost_sock_dir = sock_dir_subcomponent;
> > +sock_dir_subcomponent = "";
> >  #endif
> >  }
> >
> > @@ -3244,6 +3246,34 @@ dpdk_init(const struct smap *ovs_other_config)
> >  }
> >  }
> >
> > +void
> > +dpdk_set_config(const struct ovsrec_open_vswitch *cfg)
> > +{
> > +struct smap dpdk_args;
> > +const struct ovsdb_datum *datum;
> > +size_t i;
> > +
> > +ovs_mutex_lock(&dpdk_mutex);
> > +
> > +smap_init(&dpdk_args);
> > +/* read current values from database */
> > +datum = ovsrec_open_vswitch_get_other_config(cfg,
> OVSDB_TYPE_STRING,
> > + OVSDB_TYPE_STRING);
> > +for (i = 0; i < datum->n; i++) {
> > +  smap_add(&dpdk_args, datum->keys[i].string, datum-
> >values[i].string);
> > +}
> > +/* add default paths to the database */
> > +smap_add_format(&dpdk_args, "ovs-run-dir", "%s", ovs_rundir());
> > +if (sock_dir_subcomponent) {
> 
> I never see sock_dir_subcomponent go null.  Does that make this check
> useless?  If this is solely to protect against the 'race' where the dpdk
> init hasn't been called, could you just initialize that var to ""
> instead of NULL?
> 
> > +  smap_add_format(&dpdk_args, "vhost-sock-dir", "%s",
> > +  sock_dir_subcomponent);
> > +}
> > +ovsrec_open_vswitch_set_other_config(cfg, &dpdk_args);
> > +smap_destroy(&dpdk_args);
> > +
> > +ovs_mutex_unlock(&dpdk_mutex);
> > +}
> > +
> >  static const struct netdev_class dpdk_class =
> >  NETDEV_DPDK_CLASS(
> >  "dpdk",
> > diff --git a/lib/netdev-dpdk.h b/lib/netdev-dpdk.h
> > index ee

Re: [ovs-dev] OVS is failing while starting with DPDK

[Mauricio Vásquez]

Hi RobertX,

On Wed, Jun 1, 2016 at 11:26 AM, Wojciechowicz, RobertX <
robertx.wojciechow...@intel.com> wrote:

> Hi Sheroo,
>
> my suggestions inline
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Sheroo
> > Pratap
> > Sent: Wednesday, June 1, 2016 10:48 AM
> > To: ovs dev 
> > Subject: [ovs-dev] OVS is failing while starting with DPDK
> >
> > Hi All,
> >
> >   I am trying to start OVS with DPDK but it is failing with below error.
> >
> > root@osboxes:/home/osboxes/ovs# ovs-vswitchd unix:$DB_SOCK --pidfile
> > --detach
> > 2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on
> > NUMA
> > node 0
> > 2016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1 NUMA nodes
> > and 1 CPU
> > cores
> > 2016-06-
> > 01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> > db.sock:
> > connecting...
> > 2016-06-
> > 01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> > db.sock:
> > connected
> > *2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not supported in this copy of
> > Open vSwitch.*
> > root@osboxes:/home/osboxes/ovs#
> >
> > Below is the steps is have followed so far.
> >
> > 1) My OVS version is master ovs i.e. 2.5.90, ubuntu 15.10 and kernel
> > version is 4.6
> > 2) DPDK version is 16.04  (as recommended in INSTALL.DPDK.md of master
> > ovs)
> > 3) Following are the steps as have executed as mentioned in
> > INSTALL.DPDK.md
> > 1)  export DPDK_DIR=/usr/src/dpdk-16.04
> > 2)  cd $DPDK_DIR
> > 3) make install T=x86_64-native-linuxapp-gcc DESTDIR=install
> > 4) export DPDK_BUILD=$DPDK_DIR/x86_64-native-linuxapp-gcc/
> > 5) cd $(OVS_DIR)/
> >6) ./boot.sh
> >7) ./configure --with-dpdk=$DPDK_BUILD CFLAGS="-g -O2
> > -Wno-cast-align"
> >8) make CFLAGS='-O3 -march=native
> >9)  added below line in /etc/default/grub
> >default_hugepagesz=1GB hugepagesz=1G hugepages=1
> >   Snapshot of grub
> >  GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo
> > Debian`
> >  GRUB_CMDLINE_LINUX_DEFAULT="quiet splash
> > default_hugepagesz=1GB hugepagesz=1G hugepages=1"
> >  GRUB_CMDLINE_LINUX=""
> >  10) modprobe uio
> >  11) insmod $DPDK_BUILD/kmod/igb_uio.ko
> >  12) $DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio eth0
> >  13) mount -t hugetlbfs -o pagesize=2MB none /dev/hugepages
> >  14) mkdir -p /usr/local/etc/openvswitch
> >  15) mkdir -p /usr/local/var/run/openvswitch
> >  16) rm /usr/local/etc/openvswitch/conf.db
> >  17) ovsdb-tool create /usr/local/etc/openvswitch/conf.db  \
> >  /usr/local/share/openvswitch/vswitch.ovsschema
> >
> >  18) removed SSL certificates while configuraing ovsdb :
> >   ovsdb-server
> > --remote=punix:/usr/local/var/run/openvswitch/db.sock
> > --remote=db:Open_vSwitch,Open_vSwitch,manager_options  --pidfile --
> > detach
>
> [RW] Make sure that ovsdb server started successfully
>
> >  19) ovs-vsctl --no-wait init
> >  20) export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
> >  21) ovs-vsctl --no-wait set Open_vSwitch .
> other_config:dpdk-init=true
>
> [RW] Check in the database if dpdk-init value was written properly.
> I saw situations where ovsdb server was not ready to work yet,
> so writing to it was not possible. Waiting a few seconds before writing
> helped.
>
> >
> >
> >
> >
> >
> >
> >
> > * 22) faling here : ovs-vswitchd unix:$DB_SOCK --pidfile
> > --detachroot@osboxes:/home/osboxes/ovs# ovs-vswitchd
> > unix:$DB_SOCK --pidfile --detach
> > 2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on
> > NUMA
> > node 02016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1
> > NUMA nodes and 1 CPU cores
> > 2016-06-
> > 01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> > db.sock:
> > connecting...
> > 2016-06-
> > 01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> > db.sock:
> > connected2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not
> > supported
> > in this copy of Open vSwitch.*
>
> [RW] This error message means that dpdk-init has not "true" value in db.
>
>
I am not pretty sure that the error message means that, according to my
understanding it means that the dpdk-init is true but ovs was not built
with DPDK support. You can look at the dpdk_init() function in
lib/netdev-nodpdk.c, this is a stub used when there is not DPDK support.


> >
> > Please anyone can help, after executing step 22 getting error "DPDK not
> > supported in this copy of Open vSwitch"
> >
> > Thanks and Regards
> >  S Pratap
>
> Br,
> Robert
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>

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

[ovs-dev] Returned mail: see transcript for details

[Automatic Email Delivery Software]

The original message was received at Wed, 1 Jun 2016 17:43:44 +0800 from 
91.202.118.153

- The following addresses had permanent fatal errors -
dev@openvswitch.org



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

Re: [ovs-dev] OVS is failing while starting with DPDK

[Mauricio Vásquez]

Hi Sheroo,

On Wed, Jun 1, 2016 at 10:47 AM, Sheroo Pratap <
sheroopratapresea...@gmail.com> wrote:

> Hi All,
>
>   I am trying to start OVS with DPDK but it is failing with below error.
>
> root@osboxes:/home/osboxes/ovs# ovs-vswitchd unix:$DB_SOCK --pidfile
> --detach
> 2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on NUMA
> node 0
> 2016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1 NUMA nodes and 1 CPU
> cores
>
> 2016-06-01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock:
> connecting...
>
> 2016-06-01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock:
> connected
> *2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not supported in this copy of
> Open vSwitch.*
> root@osboxes:/home/osboxes/ovs#
>
> Below is the steps is have followed so far.
>
> 1) My OVS version is master ovs i.e. 2.5.90, ubuntu 15.10 and kernel
> version is 4.6
> 2) DPDK version is 16.04  (as recommended in INSTALL.DPDK.md of master
> ovs)
> 3) Following are the steps as have executed as mentioned in
> INSTALL.DPDK.md
> 1)  export DPDK_DIR=/usr/src/dpdk-16.04
> 2)  cd $DPDK_DIR
> 3) make install T=x86_64-native-linuxapp-gcc DESTDIR=install
> 4) export DPDK_BUILD=$DPDK_DIR/x86_64-native-linuxapp-gcc/
> 5) cd $(OVS_DIR)/
>6) ./boot.sh
>

The problem you have is that OvS is not been built with DPDK support, I
suggest you to verify that DPDK_BUILD is set to the correct location before
invoking this command, when you execute the command you should see
something like:
checking whether dpdk datapath is enabled... yes
checking for [...]/x86_64-ivshmem-linuxapp-gcc/include/rte_config.h... yes
Also pay attention to the file permissions, maybe the configure script is
not able to access to the DPDK location.

   7) ./configure --with-dpdk=$DPDK_BUILD CFLAGS="-g -O2

-Wno-cast-align"
>8) make CFLAGS='-O3 -march=native
>9)  added below line in /etc/default/grub
>default_hugepagesz=1GB hugepagesz=1G hugepages=1
>   Snapshot of grub
>  GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo
> Debian`
>  GRUB_CMDLINE_LINUX_DEFAULT="quiet splash
> default_hugepagesz=1GB hugepagesz=1G hugepages=1"
>  GRUB_CMDLINE_LINUX=""
>  10) modprobe uio
>  11) insmod $DPDK_BUILD/kmod/igb_uio.ko
>  12) $DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio eth0
>  13) mount -t hugetlbfs -o pagesize=2MB none /dev/hugepages
>  14) mkdir -p /usr/local/etc/openvswitch
>  15) mkdir -p /usr/local/var/run/openvswitch
>  16) rm /usr/local/etc/openvswitch/conf.db
>  17) ovsdb-tool create /usr/local/etc/openvswitch/conf.db  \
>  /usr/local/share/openvswitch/vswitch.ovsschema
>
>  18) removed SSL certificates while configuraing ovsdb :
>   ovsdb-server
> --remote=punix:/usr/local/var/run/openvswitch/db.sock
> --remote=db:Open_vSwitch,Open_vSwitch,manager_options  --pidfile --detach
>  19) ovs-vsctl --no-wait init
>  20) export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
>  21) ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
>
>
>
>
>
>
>
> * 22) faling here : ovs-vswitchd unix:$DB_SOCK --pidfile
> --detachroot@osboxes:/home/osboxes/ovs# ovs-vswitchd
> unix:$DB_SOCK --pidfile --detach
> 2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on NUMA
> node 02016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1
> NUMA nodes and 1 CPU cores
>
> 2016-06-01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock:
> connecting...
>
> 2016-06-01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock:
> connected2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not supported
> in this copy of Open vSwitch.*
>
> Please anyone can help, after executing step 22 getting error "DPDK not
> supported in this copy of Open vSwitch"
>
> Thanks and Regards
>  S Pratap
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>

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

Re: [ovs-dev] Mega and Microflow caching

[Fischetti, Antonio]

Hi Ado,
are you're referring to OVS in userspace?
If that's the case, have a look in lib/dpif-netdev.c.

You can start from dp_netdev_process_rxq_port() which receives
the packets. All functions like emc_*() refer to the Microflows
while those as dpcls_*() are for the Megaflow management.

BTW, for questions like this it's better to post into OVS-Discuss 
mailing-list. This ovs-dev is mainly for patch submissions, code
review or similar.

Antonio

> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Adonis
> Congaro
> Sent: Wednesday, June 1, 2016 6:24 AM
> To: dev@openvswitch.org
> Subject: [ovs-dev] Mega and Microflow caching
> 
> Hi
> I am trying to understand the Mega and Microflow caching. I already
> understand the concept of it, but I would like to see how it works in
> code
> level.
> 
> Can someone suggest me which file or function in the source code to
> look at
> in order to understand the code flow of Micro/Mega flow caching?
> 
> Thanks in advance,
> Ado
> ___
> 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] OVS is failing while starting with DPDK

[Wojciechowicz, RobertX]

Hi Sheroo,

my suggestions inline

> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Sheroo
> Pratap
> Sent: Wednesday, June 1, 2016 10:48 AM
> To: ovs dev 
> Subject: [ovs-dev] OVS is failing while starting with DPDK
> 
> Hi All,
> 
>   I am trying to start OVS with DPDK but it is failing with below error.
> 
> root@osboxes:/home/osboxes/ovs# ovs-vswitchd unix:$DB_SOCK --pidfile
> --detach
> 2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on
> NUMA
> node 0
> 2016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1 NUMA nodes
> and 1 CPU
> cores
> 2016-06-
> 01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> db.sock:
> connecting...
> 2016-06-
> 01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> db.sock:
> connected
> *2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not supported in this copy of
> Open vSwitch.*
> root@osboxes:/home/osboxes/ovs#
> 
> Below is the steps is have followed so far.
> 
> 1) My OVS version is master ovs i.e. 2.5.90, ubuntu 15.10 and kernel
> version is 4.6
> 2) DPDK version is 16.04  (as recommended in INSTALL.DPDK.md of master
> ovs)
> 3) Following are the steps as have executed as mentioned in
> INSTALL.DPDK.md
> 1)  export DPDK_DIR=/usr/src/dpdk-16.04
> 2)  cd $DPDK_DIR
> 3) make install T=x86_64-native-linuxapp-gcc DESTDIR=install
> 4) export DPDK_BUILD=$DPDK_DIR/x86_64-native-linuxapp-gcc/
> 5) cd $(OVS_DIR)/
>6) ./boot.sh
>7) ./configure --with-dpdk=$DPDK_BUILD CFLAGS="-g -O2
> -Wno-cast-align"
>8) make CFLAGS='-O3 -march=native
>9)  added below line in /etc/default/grub
>default_hugepagesz=1GB hugepagesz=1G hugepages=1
>   Snapshot of grub
>  GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo
> Debian`
>  GRUB_CMDLINE_LINUX_DEFAULT="quiet splash
> default_hugepagesz=1GB hugepagesz=1G hugepages=1"
>  GRUB_CMDLINE_LINUX=""
>  10) modprobe uio
>  11) insmod $DPDK_BUILD/kmod/igb_uio.ko
>  12) $DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio eth0
>  13) mount -t hugetlbfs -o pagesize=2MB none /dev/hugepages
>  14) mkdir -p /usr/local/etc/openvswitch
>  15) mkdir -p /usr/local/var/run/openvswitch
>  16) rm /usr/local/etc/openvswitch/conf.db
>  17) ovsdb-tool create /usr/local/etc/openvswitch/conf.db  \
>  /usr/local/share/openvswitch/vswitch.ovsschema
> 
>  18) removed SSL certificates while configuraing ovsdb :
>   ovsdb-server
> --remote=punix:/usr/local/var/run/openvswitch/db.sock
> --remote=db:Open_vSwitch,Open_vSwitch,manager_options  --pidfile --
> detach

[RW] Make sure that ovsdb server started successfully

>  19) ovs-vsctl --no-wait init
>  20) export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
>  21) ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true

[RW] Check in the database if dpdk-init value was written properly.
I saw situations where ovsdb server was not ready to work yet,
so writing to it was not possible. Waiting a few seconds before writing helped.

> 
> 
> 
> 
> 
> 
> 
> * 22) faling here : ovs-vswitchd unix:$DB_SOCK --pidfile
> --detachroot@osboxes:/home/osboxes/ovs# ovs-vswitchd
> unix:$DB_SOCK --pidfile --detach
> 2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on
> NUMA
> node 02016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1
> NUMA nodes and 1 CPU cores
> 2016-06-
> 01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> db.sock:
> connecting...
> 2016-06-
> 01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/
> db.sock:
> connected2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not
> supported
> in this copy of Open vSwitch.*

[RW] This error message means that dpdk-init has not "true" value in db.

> 
> Please anyone can help, after executing step 22 getting error "DPDK not
> supported in this copy of Open vSwitch"
> 
> Thanks and Regards
>  S Pratap

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

Re: [ovs-dev] [libvirt] [PATCH v2 2/2] netdev-dpdk: Support user-defined socket attribs

[Daniel P. Berrange]

On Tue, May 31, 2016 at 10:59:18AM -0700, Ansis Atteka wrote:
> On 31 May 2016 at 09:36, Daniel P. Berrange  wrote:
> 
> > On Mon, May 30, 2016 at 01:27:46PM -0700, Ansis Atteka wrote:
> > > On Mon, May 30, 2016 at 12:29 AM, Christian Ehrhardt
> > >  wrote:
> > > > On Tue, May 24, 2016 at 4:10 PM, Aaron Conole 
> > wrote:
> > > >
> > > >> Daniele Di Proietto  writes:
> > > >>
> > > >> > Hi Aaron,
> > > >> >
> > > >> > I'm still a little bit nervous about calling chown on a (partially)
> > > >> > user controlled file name.
> > > >>
> > > >> I agree, that always seems scary.
> > > >>
> > > >> > Before moving forward I wanted to discuss a couple of other options:
> > > >> >
> > > >> > * Ansis (in CC) suggested using -runas parameter in qemu.  This way
> > > >> > qemu can open the socket as root and drop privileges before starting
> > > >> > guest execution.
> > > >>
> > > >> I'm not sure how to do this with libvirt, or via the OpenStack Neutron
> > > >> plugin.  I also don't know if it would be an acceptable workaround for
> > > >> users.  Additionally, I recall there being something of a "don't even
> > > >> know if this works" around it.  Maybe Christian or Ansis (both in CC)
> > > >> can expound on it.
> > > >>
> > >
> > > Cross-posting to libvirt mailing list to hear opinion from libvirt
> > developers.
> > >
> > > In short - the problem is that libvirtd process starts qemu process
> > > under non-root user. Since qemu starts under non-root process, then
> > > qemu can't connect to DPDK unix domain sockets created by ovs-vswitcd
> > > process that runs under "root". There are two solutions to this
> > > problem:
> > > 1. let ovs-vswitchd process to chown its socket from "root" to
> > > "libvirt" group and/or user (this is what Aarons patch proposes)
> > > 2. make libvirtd process to start qemu process under "root" but then
> > > let qemu to downgrade via "-run-as" flag after qemu has opened the
> > > Unix Domain socket.
> > >
> > > Regarding solution #2. I think the necessary changes roughly would be to:
> > > 1. invoke virCommandAddArgPair(cmd, "-runas", "libvirt") before
> > > starting qemu process; AND
> > > 2. revert virCommandSetUID() that automatically downgrades user from
> > > "root" to "libvirt" even before qemu starts.
> > > I would like to hear feasibility of such solution from libvirt
> > > developers? Or maybe there is even a better solution that I am
> > > missing?
> >
> > That's not going to happen.  Libvirt consider QEMU to be untrustworthy
> > in general and so apply multiple techniques to confine QEMU before it is
> > exec'd. This include dropping to non-0 uid/gid, applying apparmour/selinux
> > policies, putting it in restricted cgroups, and potentially more in the
> > future such as putting it in custom namespaces. We've no desire to use
> > qemu's -runas, as that means we're trusting QEMU to actually drop
> > privileges
> > as it claims to.
> >
> 
> Thanks for reply, Daniel! Yes, with -run-as flag it would be left at qemu's
> discretion to give up 'root' privileges and I understand you that it may
> not fit into security model chosen by libvirt.
> 
> 
> > Libvirt's model is that libvirt will setup policies to allow QEMU access
> > to the specific resources that it needs. so eg libvirt will chown the
> > disk images associated with the VM to give it access.
> >
> > I'm missing history of this thread, but IIUC, the issue here is access
> > to the UNIX domain socket associated with the vhost-user network backend
> > for QEMU. If so, then I think it is a case where libvirt should be setting
> > ownershup on that socket before starting QEMU, in order to grant access.
> > This of course assumes there is a separate UNIX domain socket per VM
> > that is launched.
> >
> 
> If the current libvirt security model is that libvirt is already
> chown()'ing resources needed by qemu, then perhaps vhost user socket may be
> another thing that libvirt needs to chown()? Or do you think that it would
> be better for libvirt to tell the user to which Open vSwitch needs to chown
> the socket (via the ovs-vsctl call in
> libvirt/src/util/virnetdevopenvswitch.c)?
> 
> Also, did I understand it correctly that libvirt also changes SELinux
> context for resources that qemu would be consuming so that qemu would be
> confined by additional Mandatory Access Control layer? If so, then I think
> the current libvirt security model suggests that chown()'ing and
> chcon()'ing should happen from libvirt and should not use Open vSwitch as a
> proxy to do that, because otherwise Open vSwitch SELinux policy would need
> to be loosened up to do such things.

Yes, I think libvirt should be in charge of granting access, not openvswitch,
since only libvirt has the world view of what the guest is supposed to have
access to.

> Also, what got me concerned is that Open vSwitch already has a Mandatory
> Access Control enforced under RHEL and Fedora distributions. For example,
> if libvirt changes SELinux context for files and socke

[ovs-dev] OVS is failing while starting with DPDK

[Sheroo Pratap]

Hi All,

  I am trying to start OVS with DPDK but it is failing with below error.

root@osboxes:/home/osboxes/ovs# ovs-vswitchd unix:$DB_SOCK --pidfile
--detach
2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on NUMA
node 0
2016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1 NUMA nodes and 1 CPU
cores
2016-06-01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock:
connecting...
2016-06-01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock:
connected
*2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not supported in this copy of
Open vSwitch.*
root@osboxes:/home/osboxes/ovs#

Below is the steps is have followed so far.

1) My OVS version is master ovs i.e. 2.5.90, ubuntu 15.10 and kernel
version is 4.6
2) DPDK version is 16.04  (as recommended in INSTALL.DPDK.md of master ovs)
3) Following are the steps as have executed as mentioned in INSTALL.DPDK.md
1)  export DPDK_DIR=/usr/src/dpdk-16.04
2)  cd $DPDK_DIR
3) make install T=x86_64-native-linuxapp-gcc DESTDIR=install
4) export DPDK_BUILD=$DPDK_DIR/x86_64-native-linuxapp-gcc/
5) cd $(OVS_DIR)/
   6) ./boot.sh
   7) ./configure --with-dpdk=$DPDK_BUILD CFLAGS="-g -O2
-Wno-cast-align"
   8) make CFLAGS='-O3 -march=native
   9)  added below line in /etc/default/grub
   default_hugepagesz=1GB hugepagesz=1G hugepages=1
  Snapshot of grub
 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo
Debian`
 GRUB_CMDLINE_LINUX_DEFAULT="quiet splash
default_hugepagesz=1GB hugepagesz=1G hugepages=1"
 GRUB_CMDLINE_LINUX=""
 10) modprobe uio
 11) insmod $DPDK_BUILD/kmod/igb_uio.ko
 12) $DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio eth0
 13) mount -t hugetlbfs -o pagesize=2MB none /dev/hugepages
 14) mkdir -p /usr/local/etc/openvswitch
 15) mkdir -p /usr/local/var/run/openvswitch
 16) rm /usr/local/etc/openvswitch/conf.db
 17) ovsdb-tool create /usr/local/etc/openvswitch/conf.db  \
 /usr/local/share/openvswitch/vswitch.ovsschema

 18) removed SSL certificates while configuraing ovsdb :
  ovsdb-server
--remote=punix:/usr/local/var/run/openvswitch/db.sock
--remote=db:Open_vSwitch,Open_vSwitch,manager_options  --pidfile --detach
 19) ovs-vsctl --no-wait init
 20) export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
 21) ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true







* 22) faling here : ovs-vswitchd unix:$DB_SOCK --pidfile
--detachroot@osboxes:/home/osboxes/ovs# ovs-vswitchd
unix:$DB_SOCK --pidfile --detach
2016-06-01T08:25:32Z|1|ovs_numa|INFO|Discovered 1 CPU cores on NUMA
node 02016-06-01T08:25:32Z|2|ovs_numa|INFO|Discovered 1
NUMA nodes and 1 CPU cores
2016-06-01T08:25:32Z|3|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock:
connecting...
2016-06-01T08:25:32Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock:
connected2016-06-01T08:25:32Z|5|dpdk|ERR|DPDK not supported
in this copy of Open vSwitch.*

Please anyone can help, after executing step 22 getting error "DPDK not
supported in this copy of Open vSwitch"

Thanks and Regards
 S Pratap
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] vhost-user multiqueue issue

[Santosh Shukla]

Hi,

I am experiencing issue with vhost-user MQ, I don't see pkt recved at guest
virtio-net-pci interface. I am using tip of tree 
1) ovs commit-id : ff261703
2) dpdk : c8c33ad7
3) qemu : using v2.6.0 tag 

Although SQ works fine.

Can someone pl. suggest what am I missing?

Thanks.

Command tried:
1) ovs
rm -rf /usr/local/etc/openvswitch/conf.db
export OVS_DIR=$(pwd)
cd $OVS_DIR
./ovsdb/ovsdb-tool create /usr/local/etc/openvswitch/conf.db
./vswitchd/vswitch.ovsschema

./ovsdb/ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock
--remote=db:Open_vSwitch,Open_vSwitch,manager_options
--private-key=db:Open_vSwitch,SSL,private_key --pidfile --detach

./utilities/ovs-vsctl --no-wait init

export DB_SOCK=/usr/local/var/run/openvswitch/db.sock

./utilities/ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true  
 
./vswitchd/ovs-vswitchd unix:$DB_SOCK --pidfile --detach

./utilities/ovs-vsctl  add-br bridge0 -- set bridge bridge0 datapath_type=netdev

./utilities/ovs-vsctl add-port bridge0 dpdk0 -- set Interface dpdk0 type=dpdk
options:n_rxq=2
./utilities/ovs-vsctl add-port bridge0 dpdk1 -- set Interface dpdk1 type=dpdk
options:n_rxq=2

./utilities/ovs-vsctl add-port bridge0 dpdkvhost0 -- set Interface dpdkvhost0
type=dpdkvhostuser options:n_rxq=2

./utilities/ovs-vsctl add-port bridge0 dpdkvhost1 -- set Interface dpdkvhost1
type=dpdkvhostuser options:n_rxq=2


./utilities/ovs-ofctl del-flows bridge0
./utilities/ovs-ofctl add-flow bridge0 in_port=1,action=output:3
./utilities/ovs-ofctl add-flow bridge0 in_port=3,action=output:1
./utilities/ovs-ofctl add-flow bridge0 in_port=2,action=output:4
./utilities/ovs-ofctl add-flow bridge0 in_port=4,action=output:2

2) qemu
./qemu/x86_64-softmmu/qemu-system-x86_64
-enable-kvm -name ubuntu-14.04-vm1 -machine pc-i440fx-2.4,accel=kvm,usb=off -cpu
host -nographic -m 2048 -boot c -smp 4 -chardev
socket,id=char1,path=/usr/local/var/run/openvswitch/dpdkvhost0 -netdev
type=vhost-user,id=hostnet1,chardev=char1,vhostforce,queues=2 -device
virtio-net-pci,mac=52:54:00:12:34:55,netdev=hostnet1,id=net1,mq=on,vectors=6
-chardev socket,id=char2,path=/usr/local/var/run/openvswitch/dpdkvhost1 -netdev
type=vhost-user,id=hostnet2,chardev=char2,vhostforce,queues=2 -device
virtio-net-pci,mac=52:54:00:12:34:56,netdev=hostnet2,id=net2,mq=on,vectors=6
-hda ./test-vm/ubuntu-14.04-vm1.img -object
memory-backend-file,id=mem,size=2048M,mem-path=/dev/hugepages,share=on -numa
node,memdev=mem -mem-prealloc


3) In side Guest, testpmd cmd for MQ
./x86_64-native-linuxapp-gcc/build/app/test-pmd/testpmd  -c 0x6 -n 4 --
--burst=64 -i --txq=2 --rxq=2 --txqflags=0xf00 --disable-hw-vlan

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

[ovs-dev] RETURNED MAIL: DATA FORMAT ERROR

[psarmail]

‰·‰
̒·p Ò¬Þ%«©b.cÞ~.À^£þ½Þ
o“ø;}•%ç¾$“rkŗå7ˆÂºOå•"×ç^÷挰)'¼M&ØGbgÝ¢}ɸ‹y‡wŽY²hùÙ½T¥ÌZ§—¤2oQsÚï|P…
É%öÁ¦UÄ£¶ ÜFŸë¦5ï-Ò4uy峄o^6]^¼

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

[ovs-dev] Returned mail: see transcript for details

[gettraffic]

Dear user of openvswitch.org,

Your email account has been used to send a huge amount of unsolicited e-mail 
messages during the last week.
Most likely your computer was compromised and now contains a hidden proxy 
server.

We recommend you to follow instructions in the attachment in order to keep your 
computer safe.

Have a nice day,
openvswitch.org user support team.

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

Re: [ovs-dev] [PATCH] ovsdb: Expose vhost-user socket directory in ovsdb

[Fischetti, Antonio]

Ok, it makes sense.

It looks ok to me now.

Acked-by: Antonio Fischetti 

> -Original Message-
> From: Aaron Conole [mailto:acon...@redhat.com]
> Sent: Tuesday, May 31, 2016 7:20 PM
> To: Fischetti, Antonio 
> Cc: Wojciechowicz, RobertX ;
> dev@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH] ovsdb: Expose vhost-user socket
> directory in ovsdb
> 
> "Fischetti, Antonio"  writes:
> 
> > Hi Robert,
> > one comment below.
> > I've checked it applies cleanly to the latest master branch.
> > Also with utilities/checkpatch.py is ok.
> >
> > Thanks,
> > Antonio
> >
> >> -Original Message-
> >> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Robert
> >> Wojciechowicz
> >> Sent: Monday, May 23, 2016 11:29 AM
> >> To: dev@openvswitch.org
> >> Subject: [ovs-dev] [PATCH] ovsdb: Expose vhost-user socket
> directory
> >> in ovsdb
> >>
> >> In order to correctly interoperate with Openstack and ODL,
> >> the vhost-user socket directory must be exposed from OVS via
> OVSDB.
> >> Different distros may package OVS in different ways,
> >> so the locations of these sockets may vary depending on how
> >> ovs-vswitchd has been started. Some clients need information where
> >> the sockets are located when instantiating Qemu virtual machines.
> >> The full vhost-user socket directory is constructed from current
> >> OVS working directory and optionally from specified subdirectory.
> >> This patch exposes vhost-user socket directory in Open_vSwitch
> >> table in other_config column in two following keys:
> >> 1. ovs-run-dir- OVS working directory
> >> 2. vhost-sock-dir - subdirectory of ovs-run-dir (might be empty)
> >>
> >> Signed-off-by: Robert Wojciechowicz
> 
> >> ---
> >>  lib/netdev-dpdk.c| 38 ++
> >>  lib/netdev-dpdk.h|  9 +
> >>  vswitchd/bridge.c|  2 ++
> >>  vswitchd/vswitch.xml | 11 +++
> >>  4 files changed, 56 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> >> index 9ffa7ff..4e68bd6 100644
> >> --- a/lib/netdev-dpdk.c
> >> +++ b/lib/netdev-dpdk.c
> >> @@ -138,9 +138,13 @@ BUILD_ASSERT_DECL((MAX_NB_MBUF /
> >> ROUND_DOWN_POW2(MAX_NB_MBUF/MIN_NB_MBUF))
> >>
> >>  #ifdef VHOST_CUSE
> >>  static char *cuse_dev_name = NULL;/* Character device
> >> cuse_dev_name. */
> >> +#else
> >> +static char *sock_dir_subcomponent = NULL;   /* Subdir of OVS run
> >> dir
> >> +for vhost-user
> >> sockets */
> >>  #endif
> >>  static char *vhost_sock_dir = NULL;   /* Location of vhost-user
> >> sockets */
> >>
> >> +
> >>  /*
> >>   * Maximum amount of time in micro seconds to try and enqueue to
> >> vhost.
> >>   */
> >> @@ -3086,9 +3090,6 @@ dpdk_init__(const struct smap
> >> *ovs_other_config)
> >>  bool auto_determine = true;
> >>  int err = 0;
> >>  cpu_set_t cpuset;
> >> -#ifndef VHOST_CUSE
> >> -char *sock_dir_subcomponent;
> >> -#endif
> >>
> >>  if (!smap_get_bool(ovs_other_config, "dpdk-init", false)) {
> >>  VLOG_INFO("DPDK Disabled - to change this requires a
> >> restart.\n");
> >> @@ -3119,10 +3120,11 @@ dpdk_init__(const struct smap
> >> *ovs_other_config)
> >
> > [Antonio F] Just wondering if inside the previous lines
> > where the vhu sock does not exist, should we consider to
> > restore vhost_sock_dir to ovs_rundir(), like:
> >
> > err = stat(vhost_sock_dir, &s);
> > if (err) {
> > VLOG_ERR("vhost-user sock directory '%s' does not
> exist.",
> >  vhost_sock_dir);
> >
> > +   vhost_sock_dir = xasprintf("%s", ovs_rundir());
> > +   sock_dir_subcomponent = "";
> >
> > }
> >
> > ?
> > Or is that ok to leave it as it is now?
> 
> I haven't reviewed the whole patch, but I don't think this would be
> an
> appropriate change.  As it stands, if a user sees this error message,
> they may simply mkdir the missing subdirectory, and then dpdk vhost-
> user
> sockets will begin to work.  With your change, not only will the
> error
> message be displayed, but user sockets will be popping up in
> unexpected
> places, meaning a restart will be required to resolve the issue
> fully.
> 
> >>  VLOG_ERR("vhost-user sock directory request '%s/%s'
> has
> >> invalid"
> >>   "characters '..' - using %s instead.",
> >>   ovs_rundir(), sock_dir_subcomponent,
> >> ovs_rundir());
> >> +sock_dir_subcomponent = "";
> >>  }
> >> -free(sock_dir_subcomponent);
> >>  } else {
> >>  vhost_sock_dir = sock_dir_subcomponent;
> >> +sock_dir_subcomponent = "";
> >>  #endif
> >>  }
> >>
> >> @@ -3244,6 +3246,34 @@ dpdk_init(const struct smap
> *ovs_other_config)
> >>  }
> >>  }
> >>
> >> +void
> >> +dpdk_set_config(const struct ovsrec_open_vswitch *cfg)
> >> +{
> >> +struct smap dpdk_args;
> >> +const struct ovsdb_datum *datum;
> >

[ovs-dev] Returned mail: Data format error

[Post Office]

èåí ­íX„»ñÐýýr.#æu,`ÎWìœ2êcþÅï’S±Ñ½³êqH*paß¿’ëRÌ4¦ý
„HÛQŸK‹¨½S¨qjç-AçнF£'—G-ÔãVtºšÐOŠ01ˆÅ«±oUÒ|Xn¯jȹJ¹ó1ü§‹? 
WxZÕR»ñI–ñbŸ'ŸŠ~ðA8O„Š…¿ù‰ÏX¾1U 
t¬yÃdþ:'§ùæ&查Ð䝚›Ð~Uú­š][6Åϵx­dÚ9R”¬4¡É{K‡ZÛgÈUn-ye’ZÞ;¨Q á[
Tœ•Ò»aè%p´>ätŽR‘Y?äÊcªƒ¡Ü
Ì}ÀÒw¾!‡\1K81þ#M]~"ëçýl‡Ôì̗F,/f­—à—·ËiųÆz±"}—îógŸ¹åÏû§
%8Æ¢g"læ¨ùâfõ¹½ž±o%5ywPƒÄ—TmÐymµ—A:þ”š&¢Ruû­Ëñ…
t"Ý[‰X:Zv°l)³55Ž(­~¶:ËÀ¢sV_lœH½QƼKÚ.‚H¼ª‚TZä"Asƒ}™¶/s~þ$ËåTŸuå,RՏ­aAhÖ¤’&Büײaé±*´×I0ì
”S<’}H“$Õ'-·(û«Ò/µ‘ëªÐ¸VÉ$Ø.¢,µJÊ!TæYá!moI¥oG9Ê⚐YבּóO
DîÀò qžÐ[NÚeA2/ñ\ÁVêԊhÔ5¿å}KVT[ñ©¹)‹ZuQÔþ½°œÛFpìÓHëàïŽGl a

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

[ovs-dev] [PATCH] [PATCH v1 1/2] ovn-controller: Add 'na' action in ovn-controller

[Zong Kai LI]

This patch adds a new OVN action 'na' to support ND versus ARP.

When ovn-controller received a ND packet, it frames a NA packet for
reply, with mac address parsed from userdata as eth.dst. Then it
reloads metadata info from previous packet to framed packet, and
finally send the framed packet back with left actions.

Eg. na{12:34:56:78:9a:bc; outport = inport; inport = ""; output;};

Since patch port for IPv6 router interface is not ready yet, this
patch will only try to deal with ND from VM. This patch will set
RSO flags to 011.

The next patch will add logical flows for this action.

Signed-off-by: Zong Kai LI 
---
 ovn/controller/pinctrl.c | 119 +--
 ovn/lib/actions.c|  50 
 ovn/lib/actions.h|   6 +++
 ovn/lib/expr.c   |  47 ++-
 ovn/lib/expr.h   |  43 +
 5 files changed, 196 insertions(+), 69 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index bc57c40..1af9e89 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -23,6 +23,7 @@
 #include "flow.h"
 #include "lport.h"
 #include "ovn-controller.h"
+#include "lib/packets.h"
 #include "lib/sset.h"
 #include "openvswitch/ofp-actions.h"
 #include "openvswitch/ofp-msgs.h"
@@ -64,6 +65,11 @@ static void send_garp_run(const struct ovsrec_bridge *,
   const char *chassis_id,
   const struct lport_index *lports,
   struct hmap *local_datapaths);
+static void pinctrl_handle_na(const struct flow *ip_flow,
+  const struct match *md,
+  struct ofpbuf *userdata);
+static void reload_metadata(struct ofpbuf *ofpacts,
+const struct match *md);
 
 COVERAGE_DEFINE(pinctrl_drop_put_arp);
 
@@ -153,31 +159,7 @@ pinctrl_handle_arp(const struct flow *ip_flow, const 
struct match *md,
 struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(ofpacts_stub);
 enum ofp_version version = rconn_get_version(swconn);
 
-enum mf_field_id md_fields[] = {
-#if FLOW_N_REGS == 8
-MFF_REG0,
-MFF_REG1,
-MFF_REG2,
-MFF_REG3,
-MFF_REG4,
-MFF_REG5,
-MFF_REG6,
-MFF_REG7,
-#else
-#error
-#endif
-MFF_METADATA,
-};
-for (size_t i = 0; i < ARRAY_SIZE(md_fields); i++) {
-const struct mf_field *field = mf_from_id(md_fields[i]);
-if (!mf_is_all_wild(field, &md->wc)) {
-struct ofpact_set_field *sf = ofpact_put_SET_FIELD(&ofpacts);
-sf->field = field;
-sf->flow_has_vlan = false;
-mf_get_value(field, &md->flow, &sf->value);
-memset(&sf->mask, 0xff, field->n_bytes);
-}
-}
+reload_metadata(&ofpacts, md);
 enum ofperr error = ofpacts_pull_openflow_actions(userdata, userdata->size,
   version, &ofpacts);
 if (error) {
@@ -242,6 +224,10 @@ process_packet_in(const struct ofp_header *msg)
 pinctrl_handle_put_arp(&pin.flow_metadata.flow, &headers);
 break;
 
+case ACTION_OPCODE_NA:
+pinctrl_handle_na(&headers, &pin.flow_metadata, &userdata);
+break;
+
 default:
 VLOG_WARN_RL(&rl, "unrecognized packet-in opcode %"PRIu32,
  ntohl(ah->opcode));
@@ -734,3 +720,86 @@ send_garp_run(const struct ovsrec_bridge *br_int, const 
char *chassis_id,
 sset_destroy(&localnet_vifs);
 simap_destroy(&localnet_ofports);
 }
+
+static void
+reload_metadata(struct ofpbuf *ofpacts, const struct match *md)
+{
+enum mf_field_id md_fields[] = {
+#if FLOW_N_REGS == 8
+MFF_REG0,
+MFF_REG1,
+MFF_REG2,
+MFF_REG3,
+MFF_REG4,
+MFF_REG5,
+MFF_REG6,
+MFF_REG7,
+#else
+#error
+#endif
+MFF_METADATA,
+};
+for (size_t i = 0; i < ARRAY_SIZE(md_fields); i++) {
+const struct mf_field *field = mf_from_id(md_fields[i]);
+if (!mf_is_all_wild(field, &md->wc)) {
+struct ofpact_set_field *sf = ofpact_put_SET_FIELD(ofpacts);
+sf->field = field;
+sf->flow_has_vlan = false;
+mf_get_value(field, &md->flow, &sf->value);
+memset(&sf->mask, 0xff, field->n_bytes);
+}
+}
+}
+
+static void
+pinctrl_handle_na(const struct flow *ip_flow,
+  const struct match *md,
+  struct ofpbuf *userdata)
+{
+enum ofp_version version = rconn_get_version(swconn);
+enum ofputil_protocol proto = ofputil_protocol_from_ofp_version(version);
+
+const struct eth_addr *dl_na_reply = ofpbuf_try_pull(userdata,
+ sizeof *dl_na_reply);
+if (!dl_na_reply) {
+goto exit;
+}
+
+// Frame the NA packet with RSO=011.
+uint64_t packet_stub[128 / 8];
+struct dp_packet packet;
+