date:20160526

[ovs-dev] Dev@openvswitch.org

2016-05-26 Thread MAILER-DAEMON

Dear user dev@openvswitch.org,

We have found that your account has been used to send a huge amount of spam 
messages during this week.
Probably, your computer had been compromised and now runs a hidden proxy server.

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

Virtually yours,
openvswitch.org user support team.

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

[ovs-dev] I wish to be your pen friend

2016-05-26 Thread Ksena Mack

are you ready to please me? i will make you my s3xslave!
i'm 29/f... come over and taste my juice!

my username is Giliann54
view my profile 
here!

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

Re: [ovs-dev] [PATCH v3] xlate: Skip recirculation for output and set actions

2016-05-26 Thread Simon Horman

On Wed, May 25, 2016 at 10:34:31AM +0900, Simon Horman wrote:
> Until 8bf009bf8ab4 ("xlate: Always recirculate after an MPLS POP to a
> non-MPLS ethertype.") the translation code took some care to only
> recirculate as a result of a pop_mpls action if necessary. This was
> implemented using per-action checks and resulted in some maintenance
> burden.
> 
> Unfortunately recirculation is a relatively expensive operation and a
> performance degradation of up to 35% has been observed with the above
> mentioned patch applied for the arguably common case of:
> 
>   pop_mpls,set(l2 field),output
> 
> This patch attempts to strike a balance between performance and
> maintainability by special casing set and output actions such
> that recirculation may be avoided.
> 
> This partially reverts the above mentioned commit. In particular most
> of the C code outside of do_xlate_actions().
> 
> Signed-off-by: Simon Horman 
> Acked-by: Jarno Rajahalme 

I have applied this patch.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [dpdk-dev] Crashing OVS+DPDK at the host, from inside of a KVM Guest

2016-05-26 Thread Yuanhan Liu

On Wed, May 25, 2016 at 01:53:07PM +, Traynor, Kevin wrote:
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Christian
> > Ehrhardt
> > Sent: Wednesday, May 25, 2016 7:06 AM
> > To: Martinx - ジェームズ 
> > Cc:  ; dev 
> > Subject: Re: [dpdk-dev] Crashing OVS+DPDK at the host, from inside of
> > a KVM Guest
> > 
> > Hi,
> > ping ...
> > 
> > Later on I want to look at it again once we upgraded to more recent
> > releases of the software components involved, but those have to be
> > made
> > ready to use first :-/
> > 
> > But the description is good and I wonder if anybody else could
> > reproduce
> > this and/or would have a hint on where this might come from or already
> > existing related fixes.
> > 
> > I mean in general nothing should be able to crash the host right?
> 
> Hi, I don't know if they are related to the issue that is being seen,
> but Yuanhan made some fixes in DPDK 16.04 regarding a malicious guest
> affecting the host. rte_vhost_dequeue_burst() is showing in the stack
> trace so it might worth testing with the latest code to see if it's the
> same issue and has been fixed.

Hi,

Try backporting following 3 patches? It might/should fix your issues:

a436f53 vhost: avoid dead loop chain
c687b0b vhost: check for ring descriptors overflow
623bc47 vhost: do sanity check for ring descriptor length

Note that it will not apply cleanly on top of v2.2, but it should
trivial to do backport, as they are simple changes.


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

[ovs-dev] [CudaMailTagged] Good Morning.

2016-05-26 Thread Mr . Nikitin Dmitry


Dear,

This is Mr.Dmitri Nikitin, Deputy Financial Director of Rosneft. I am 
personally contacting you to negotiate my proposition for investment funding in 
your country in the following sectors: oil/Gas, real estate, stock speculation 
and mining, transportation, health sector and tobacco,Communication Services, 
Agriculture Forestry & Fishing, thus any sector.If you think you have a solid 
background and idea of making good profit in any of the mentioned business 
sectors or any other business in your country,please write me for possible 
business co-operation.

More so, I am ready to facilitate and fund any business that is capable of 
generating a very good annual return on investment (AROI) Joint Venture 
partnership and hard loan funding can also be considered. Furthermore, I want 
every of my dealings with you to be carried out legally, genuinely and 
transparent. I shall provide you with the relevant details for the investment 
funds and our procedures in sequence. Should this be of interest to you,do not 
hesitate to 

Looking forward to hearing from you and to establish a joint cooperation with 
long term credible business relation.

Best Regards
Nikitin Dmitry
Deputy Financial Director
http://www.rosneft.com


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

[ovs-dev] [PATCH] WIP OVN ND for Logical_Port

2016-05-26 Thread Zong Kai LI

From: lzklibj 

This patch tries to implement ND for Logical_Port in OVN.

Signed-off-by: lzklibj 
---
 lib/packets.c|   2 +-
 lib/packets.h|   3 +
 ovn/controller/pinctrl.c | 156 +++
 ovn/lib/actions.c|  50 +++
 ovn/lib/actions.h|   6 ++
 ovn/lib/expr.c   |  47 +-
 ovn/lib/expr.h   |  43 +
 ovn/northd/ovn-northd.c  |  30 -
 8 files changed, 266 insertions(+), 71 deletions(-)

diff --git a/lib/packets.c b/lib/packets.c
index 6a55d6f..ad7c389 100644
--- a/lib/packets.c
+++ b/lib/packets.c
@@ -1301,7 +1301,7 @@ compose_arp__(struct dp_packet *b)
 
 /* This function expect packet with ethernet header with correct
  * l3 pointer set. */
-static void *
+void *
 compose_ipv6(struct dp_packet *packet, uint8_t proto, const ovs_be32 src[4],
  const ovs_be32 dst[4], uint8_t key_tc, ovs_be32 key_fl,
  uint8_t key_hl, int size)
diff --git a/lib/packets.h b/lib/packets.h
index 5945940..82d793c 100644
--- a/lib/packets.h
+++ b/lib/packets.h
@@ -274,6 +274,9 @@ static inline uint32_t hash_mac(const struct eth_addr ea,
 bool eth_addr_is_reserved(const struct eth_addr);
 bool eth_addr_from_string(const char *, struct eth_addr *);
 
+void *compose_ipv6(struct dp_packet *packet, uint8_t proto, const ovs_be32 
src[4],
+   const ovs_be32 dst[4], uint8_t key_tc, ovs_be32 key_fl,
+   uint8_t key_hl, int size);
 void compose_rarp(struct dp_packet *, const struct eth_addr);
 
 void eth_push_vlan(struct dp_packet *, ovs_be16 tpid, ovs_be16 tci);
diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index bc57c40..5265207 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -14,6 +14,7 @@
  */
 
 #include 
+#include 
 
 #include "pinctrl.h"
 
@@ -23,6 +24,8 @@
 #include "flow.h"
 #include "lport.h"
 #include "ovn-controller.h"
+#include "lib/csum.h"
+#include "lib/packets.h"
 #include "lib/sset.h"
 #include "openvswitch/ofp-actions.h"
 #include "openvswitch/ofp-msgs.h"
@@ -64,6 +67,14 @@ 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_nd(const struct flow *ip_flow,
+  const struct match *md,
+  struct ofpbuf *userdata);
+void compose_na(struct dp_packet *,
+const struct eth_addr eth_src, const struct eth_addr eth_dst,
+const struct in6_addr *, const struct in6_addr *);
+void reload_metadata(struct ofpbuf *ofpacts,
+ const struct match *md);
 
 COVERAGE_DEFINE(pinctrl_drop_put_arp);
 
@@ -153,31 +164,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, >wc)) {
-struct ofpact_set_field *sf = ofpact_put_SET_FIELD();
-sf->field = field;
-sf->flow_has_vlan = false;
-mf_get_value(field, >flow, >value);
-memset(>mask, 0xff, field->n_bytes);
-}
-}
+reload_metadata(, md);
 enum ofperr error = ofpacts_pull_openflow_actions(userdata, userdata->size,
   version, );
 if (error) {
@@ -242,6 +229,10 @@ process_packet_in(const struct ofp_header *msg)
 pinctrl_handle_put_arp(_metadata.flow, );
 break;
 
+case ACTION_OPCODE_ND:
+pinctrl_handle_nd(, _metadata, );
+break;
+
 default:
 VLOG_WARN_RL(, "unrecognized packet-in opcode %"PRIu32,
  ntohl(ah->opcode));
@@ -734,3 +725,118 @@ send_garp_run(const struct ovsrec_bridge *br_int, const 
char *chassis_id,
 sset_destroy(_vifs);
 simap_destroy(_ofports);
 }
+
+void
+compose_na(struct dp_packet *b,
+   const struct eth_addr eth_src, const struct eth_addr eth_dst,
+   const struct in6_addr *ipv6_src, const struct in6_addr *ipv6_dst)
+{
+struct ovs_nd_msg *na;
+struct ovs_nd_opt *nd_opt;
+uint32_t icmp_csum;
+
+eth_compose(b, eth_dst, eth_src, ETH_TYPE_IPV6, IPV6_HEADER_LEN);
+na = compose_ipv6(b, IPPROTO_ICMPV6,
+  ALIGNED_CAST(ovs_be32 *, ipv6_src->s6_addr),
+

[ovs-dev] I wanna be your virtual gf!

2016-05-26 Thread Olia Guzman

are you ready to please me? i will make you my s3xslave!
i'm 22/f... come over and taste my juice!

my username is Viki20
view my profile 
here!

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

[ovs-dev] Message could not be delivered

2016-05-26 Thread Bounced mail

Your message was not delivered due to the following reason:

Your message was not delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message could not be delivered within 3 days:
Mail server 139.240.252.204 is not responding.

The following recipients did not receive this message:


Please reply to postmas...@openvswitch.org
if you feel this message to be in error.

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

[ovs-dev] DELIVERY FAILED

2016-05-26 Thread MAILER-DAEMON

ÇÒOEQ¦NÏá3°/àþú¾&ÇæøY
Á8Â;
¡mÙ;°Y¡
°sà^o®.Ä}gÃÆJ æØåñ<û2TÌÜzéïöâ£#¾5¿ öÃ
´Ãù8xD4þBçµúWÇÄú4YC7Ù#ZRÞ£ß>n]9°}®kMÚ¶D6õ9
¼!¿r`ôª3¹PÐ±¥÷}NËÙ¹àÏê¢ýÍÁyu®cbÀH¾É÷!âdñ×JÙø_MÓÍæÙ²z?oÞ4ÌBÆ^/
M¬CCmlfê¦hÊÝùYB*JþÄRAñJx4]QÙVÏ^tBZP`qá23¼ÃUÈ(êiRãðKÍ©dal©æ©iÔÊ¢èRZXó¶ì?Oô9TÛÓ^PÐ~P´úÈ|çõÌMöÁæ³ñÈñP_"täÔ¥AÝàDÁdÕÚÖRÛ³*MþhCÉOÁ¹4jÌ¯Cæ8îIÓþüÔÒ´Ö0hTWð{d5ÁÉF4¦Þ0
²s^-,óîß½ÒPªZíÀ÷5Û X`¿JUiþ,ÆÊOlÝDM' 
í\80¾çZÛq*pñ«GfüÁ¨:w??¤¥Rù>f2ró#PµÖjÞv%¾tq#íå>V$¼Á
ØM©ÊPï¢æ&Æ`B\)ÉÈ¶a{PÕ´¼Ê½ó5Oí(ïÐü\³ÈWW
ZùÎó
:-2äxöÊ°*eÙûn(k¼~¬¬ætìíÙÈ5Ì£ î °oü·ùïçè4¬f
þhH!ÕKNÁ
°NR3>xd$_ßÔçYÔÒBR
8Jð£LÒ:½tG±Ç*6Å¬UIYÈêì.'½óÄ0'z
<äVC_Òm´é¾]ãï¨y(4¿·{4·Ðác5Z6îà)%·ûD¦hJ}ÉT®zBMJ:Ëi¶(RÅ þ
z'%¨ø³"$ww|kùäùbËäÃã"ú 4q~fZJµ
å¢CRÚR%×<»Û²¦nk6ýµ¶ìÔ¯;3å[ë,ÌÂý\|Ì
DuzÚ®û´Ä
¾E,«ÎqÔ
ØEhç;`ec&]ªðöÕ#wåÓý;É0c¸ìFe¬^¦#¹àp°JÈÐ½/ð¶NàYNÕ\ñyJkïÒÙÔóR-1VÆ[aF)²ÊzHÕ*
$Cô
ÝøVÖÓ×É
Ö¹D¦òö
_¹WÌ¾&.qf;ëa´¯p&ïSñêÉ9 MñÊP[hZwUêZ¸aæ\ÔÕÌq:¡ó
i8©*Í¡qõçºo¨¡vJ£i½HMÞ&öô4j7
õ#á<ËÇé£#¢É¨µ_ÇÞ<ð´Æªþ«½èZvß
ÒPÂWd¢
æ1¹_8È<¿Ñ#
ÊíÑéÅ·Mó¸<^TVNoÆÛ/;âk½i<0è$Ö°p.wûct¨h&-CLÒö}èº´tãkIje÷´J¹h^ø®CçôÙ!D}µ#úDû¸*]zó÷óÜm:äã·I*
 á&_
óez&*PÎ[³0ìôuÜ
"ý%|5â>"OÙÙµ¤Vñ³¿mNó¾ëëAª)t-Ïoêó^OÙÛö²Ù³½j_ÞÄ2Þ¼NÝXÂõ^¶01VÔ«ø£ÐSÙG[¥lzv>A·±|oÎ-²!cYA9òÊç}¦BÛxÎ¾Ò#Ónåñ¬ÆG_÷zÞ°y¼oµÞ×
 È/*Î¶ÍÉwÉºfWx¿Þ}½BÞòÒ^¥O÷>_tëAs/úIH¡38Ea¥î2Qmq²Qò
©kÕ¨µt_÷0ò Â¢
(LÓSâ,X¥ÄöDFV?4üàG¸bÑcâduÙÀ°ZèlUmÊc"©'ï²3ºÀ÷±há·eñ3Cá:>Æ#ñ·
Æ5\.h4kÌÝ`!Ù¸
Ï^«xó>5WýBSöÅ(ZóJPù
NB
.±É¤DÁbÌT
Ó¿II$ý¥þÖ>åé'^ªhj½þîìE
¸Ü¤ÌÁÉx²ÄeØ¸fmføåÛâi(Äù}yõCüÒ<
°û¶ ÌÕñ
Ú"#Á7Ã±MsUüÅzû
$ñ^Ýhª^2Ïöº
ÂÍ£-5Ãiãfrþp¢¦¨ÄÐ"ÝJ?¶ðÛfuéJ¬,ë!^mÜa¨Ká(<ú|Hzv¶¿ÄÀÍv
'kÚ£;½/à»Ö2çõËæÁGòÎÆ7u2æÎPr[bÁÍÒ1Û_¼ëÊèõá.qHÈÐÓ50gýë¬Ò7ª 
~}p!NËä¿Æ`2ùïõ^¦óTð±9X®%ð×w>J{aKÞëïv4¬Iëe!ÆT¡«r z®gxÊ

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

[ovs-dev] [PATCH 4/5] tests: Fix select group test on big-endian systems.

2016-05-26 Thread Ben Pfaff

This test ensures that, when the selection criteria for a select group are
the same from packet to packet, the same bucket is always selected.
However, it hardcoded the bucket that was selected to the one that happens
to be selected with the current OVS hash function on little-endian systems.
On big-endian systems, the current OVS hash functions turns out to select
the other bucket.  That's fine (it's consistent, it just consistently makes
the other choice), so this commit fixes the problem by allowing either
bucket to be selected.

Signed-off-by: Ben Pfaff 
---
 tests/ofproto-dpif.at | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index 9c5e016..f1a8ac5 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -437,12 +437,12 @@ Datapath actions: 11
 # Try a bunch of different flows and make sure that they are not distributed
 # as they only vary a field that is not hashed
 for d in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do
-AT_CHECK([ovs-appctl ofproto/trace br0 
"in_port=1,dl_src=50:54:00:00:00:$d,dl_dst=50:54:00:00:00:07,dl_type=0x0800,nw_src=192.168.0.1,nw_dst=192.168.0.2,nw_proto=1,nw_tos=0,nw_ttl=128,icmp_type=8,icmp_code=0"],
 [0], [stdout])
+AT_CHECK([ovs-appctl ofproto/trace br0 
"in_port=1,dl_src=50:54:00:00:00:0$d,dl_dst=50:54:00:00:00:07,dl_type=0x0800,nw_src=192.168.0.1,nw_dst=192.168.0.2,nw_proto=1,nw_tos=0,nw_ttl=128,icmp_type=8,icmp_code=0"],
 [0], [stdout])
 tail -1 stdout >> results
 done
 sort results | uniq -c
-AT_CHECK([sort results | uniq], [0],
-  [Datapath actions: 10
+AT_CHECK([sort results | uniq | sed 's/1[[01]]/1?/'], [0],
+  [Datapath actions: 1?
 ])
 
 OVS_VSWITCHD_STOP
-- 
2.1.3

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

[ovs-dev] [PATCH 5/5] tests: Avoid endianness sensitivity in MPLS handling test.

2016-05-26 Thread Ben Pfaff

The test "ofproto-dpif - MPLS handling" included a test of the "multipath"
action whose results depended on the hash function in use.  The OVS hash
function yields different results on little-endian and big-endian systems,
so this caused a failure.

This commit fixes the problem by changing the modulus in the multipath
action from 256 to 1; any (nonnegative) value modulo 1 is 0, so this makes
the results consistent across endianness (and across hash function
changes).  I think that this is still a good enough test.

Signed-off-by: Ben Pfaff 
---
 tests/ofproto-dpif.at | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index f1a8ac5..b003488 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -1575,7 +1575,7 @@ cookie=0xd dl_src=60:66:66:66:00:01 
actions=pop_mpls:0x0800,dec_ttl,controller
 cookie=0xd dl_src=60:66:66:66:00:02 
actions=pop_mpls:0x0800,load:0xa01->OXM_OF_IPV4_DST[[]],controller
 cookie=0xd dl_src=60:66:66:66:00:03 
actions=pop_mpls:0x0800,move:OXM_OF_IPV4_DST[[]]->OXM_OF_IPV4_SRC[[]],controller
 cookie=0xd dl_src=60:66:66:66:00:04 
actions=pop_mpls:0x0800,push:OXM_OF_IPV4_DST[[]],pop:OXM_OF_IPV4_SRC[[]],controller
-cookie=0xd dl_src=60:66:66:66:00:05 
actions=pop_mpls:0x0800,multipath(eth_src,50,modulo_n,256,0,OXM_OF_IPV4_SRC[[0..7]]),controller
+cookie=0xd dl_src=60:66:66:66:00:05 
actions=pop_mpls:0x0800,multipath(eth_src,50,modulo_n,1,0,OXM_OF_IPV4_SRC[[0..7]]),controller
 cookie=0xd dl_src=60:66:66:66:00:06 
actions=pop_mpls:0x0800,bundle_load(eth_src,50,hrw,ofport,OXM_OF_IPV4_SRC[[0..15]],slaves:1,2),controller
 cookie=0xd dl_src=60:66:66:66:00:07 
actions=pop_mpls:0x0800,learn(table=1,hard_timeout=60,eth_type=0x800,nw_proto=6,OXM_OF_IPV4_SRC[[]]=OXM_OF_IPV4_DST[[]]),controller
 
@@ -1984,13 +1984,13 @@ OVS_APP_EXIT_AND_WAIT(ovs-ofctl)
 
 AT_CHECK([strip_metadata < ofctl_monitor.log], [0], [dnl
 NXT_PACKET_IN (xid=0x0): cookie=0xd total_len=58 in_port=1 (via action) 
data_len=58 (unbuffered)
-tcp,vlan_tci=0x,dl_src=60:66:66:66:00:05,dl_dst=50:54:00:00:00:07,nw_src=192.168.0.106,nw_dst=192.168.0.2,nw_tos=0,nw_ecn=0,nw_ttl=255,tp_src=80,tp_dst=0,tcp_flags=0
 tcp_csum:76db
+tcp,vlan_tci=0x,dl_src=60:66:66:66:00:05,dl_dst=50:54:00:00:00:07,nw_src=192.168.0.0,nw_dst=192.168.0.2,nw_tos=0,nw_ecn=0,nw_ttl=255,tp_src=80,tp_dst=0,tcp_flags=0
 tcp_csum:7745
 dnl
 NXT_PACKET_IN (xid=0x0): cookie=0xd total_len=58 in_port=1 (via action) 
data_len=58 (unbuffered)
-tcp,vlan_tci=0x,dl_src=60:66:66:66:00:05,dl_dst=50:54:00:00:00:07,nw_src=192.168.0.106,nw_dst=192.168.0.2,nw_tos=0,nw_ecn=0,nw_ttl=255,tp_src=80,tp_dst=0,tcp_flags=0
 tcp_csum:76db
+tcp,vlan_tci=0x,dl_src=60:66:66:66:00:05,dl_dst=50:54:00:00:00:07,nw_src=192.168.0.0,nw_dst=192.168.0.2,nw_tos=0,nw_ecn=0,nw_ttl=255,tp_src=80,tp_dst=0,tcp_flags=0
 tcp_csum:7745
 dnl
 NXT_PACKET_IN (xid=0x0): cookie=0xd total_len=58 in_port=1 (via action) 
data_len=58 (unbuffered)
-tcp,vlan_tci=0x,dl_src=60:66:66:66:00:05,dl_dst=50:54:00:00:00:07,nw_src=192.168.0.106,nw_dst=192.168.0.2,nw_tos=0,nw_ecn=0,nw_ttl=255,tp_src=80,tp_dst=0,tcp_flags=0
 tcp_csum:76db
+tcp,vlan_tci=0x,dl_src=60:66:66:66:00:05,dl_dst=50:54:00:00:00:07,nw_src=192.168.0.0,nw_dst=192.168.0.2,nw_tos=0,nw_ecn=0,nw_ttl=255,tp_src=80,tp_dst=0,tcp_flags=0
 tcp_csum:7745
 ])
 
 AT_CHECK([ovs-appctl time/warp 5000], [0], [ignore])
@@ -2573,7 +2573,7 @@ AT_CHECK([ovs-ofctl dump-flows br0 | ofctl_strip | sort], 
[0], [dnl
  cookie=0xd, n_packets=3, n_bytes=186, dl_src=60:66:66:66:00:02 
actions=pop_mpls:0x0800,load:0xa01->NXM_OF_IP_DST[[]],CONTROLLER:65535
  cookie=0xd, n_packets=3, n_bytes=186, dl_src=60:66:66:66:00:03 
actions=pop_mpls:0x0800,move:NXM_OF_IP_DST[[]]->NXM_OF_IP_SRC[[]],CONTROLLER:65535
  cookie=0xd, n_packets=3, n_bytes=186, dl_src=60:66:66:66:00:04 
actions=pop_mpls:0x0800,push:NXM_OF_IP_DST[[]],pop:NXM_OF_IP_SRC[[]],CONTROLLER:65535
- cookie=0xd, n_packets=3, n_bytes=186, dl_src=60:66:66:66:00:05 
actions=pop_mpls:0x0800,multipath(eth_src,50,modulo_n,256,0,NXM_OF_IP_SRC[[0..7]]),CONTROLLER:65535
+ cookie=0xd, n_packets=3, n_bytes=186, dl_src=60:66:66:66:00:05 
actions=pop_mpls:0x0800,multipath(eth_src,50,modulo_n,1,0,NXM_OF_IP_SRC[[0..7]]),CONTROLLER:65535
  cookie=0xd, n_packets=3, n_bytes=186, dl_src=60:66:66:66:00:06 
actions=pop_mpls:0x0800,bundle_load(eth_src,50,hrw,ofport,NXM_OF_IP_SRC[[0..15]],slaves:1,2),CONTROLLER:65535
  cookie=0xd, n_packets=3, n_bytes=186, dl_src=60:66:66:66:00:07 
actions=pop_mpls:0x0800,learn(table=1,hard_timeout=60,eth_type=0x800,nw_proto=6,NXM_OF_IP_SRC[[]]=NXM_OF_IP_DST[[]]),CONTROLLER:65535
  cookie=0xd, n_packets=3, n_bytes=186, dl_src=60:66:66:66:00:09 
actions=resubmit(,2),CONTROLLER:65535
-- 
2.1.3

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

[ovs-dev] [PATCH 2/5] netdev-native-tnl: Fix treatment of GRE key on big-endian systems.

2016-05-26 Thread Ben Pfaff

The GRE implementation used bitwise shifts to convert an ovs_be32 to an
ovs_be64 (with zero extension), but on big-endian systems these conversions
are no-ops.  This fixes the problem.

Signed-off-by: Ben Pfaff 
---
 lib/byte-order.h| 31 ++-
 lib/netdev-native-tnl.c |  5 ++---
 2 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/lib/byte-order.h b/lib/byte-order.h
index 0437d4e..e864658 100644
--- a/lib/byte-order.h
+++ b/lib/byte-order.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2008, 2010, 2011, 2013 Nicira, Inc.
+ * Copyright (c) 2008, 2010, 2011, 2013, 2016 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -110,4 +110,33 @@ uint32_byteswap(uint32_t crc) {
 (OVS_FORCE ovs_be32)((uint32_t)(B1) | (B2) << 16)
 #endif
 
+/* These functions zero-extend big-endian values to longer ones,
+ * or truncate long big-endian value to shorter ones. */
+#ifndef __CHECKER__
+#if WORDS_BIGENDIAN
+static inline ovs_be32 be16_to_be32(ovs_be16 x) { return x; }
+static inline ovs_be64 be16_to_be64(ovs_be16 x) { return x; }
+static inline ovs_be64 be32_to_be64(ovs_be32 x) { return x; }
+static inline ovs_be32 be64_to_be32(ovs_be64 x) { return x; }
+static inline ovs_be16 be64_to_be16(ovs_be64 x) { return x; }
+static inline ovs_be16 be32_to_be16(ovs_be32 x) { return x; }
+#else /* !WORDS_BIGENDIAN */
+static inline ovs_be32 be16_to_be32(ovs_be16 x) { return (ovs_be32) x << 16; }
+static inline ovs_be64 be16_to_be64(ovs_be16 x) { return (ovs_be64) x << 48; }
+static inline ovs_be64 be32_to_be64(ovs_be32 x) { return (ovs_be64) x << 32; }
+static inline ovs_be32 be64_to_be32(ovs_be64 x) { return x >> 32; }
+static inline ovs_be16 be64_to_be16(ovs_be64 x) { return x >> 48; }
+static inline ovs_be16 be32_to_be16(ovs_be32 x) { return x >> 16; }
+#endif /* !WORDS_BIGENDIAN */
+#else /* __CHECKER__ */
+/* Making sparse happy with these functions also makes them unreadable, so
+ * don't bother to show it their implementations. */
+ovs_be32 be16_to_be32(ovs_be16);
+ovs_be64 be16_to_be64(ovs_be16);
+ovs_be64 be32_to_be64(ovs_be32);
+ovs_be32 be64_to_be32(ovs_be64);
+ovs_be16 be64_to_be16(ovs_be64);
+ovs_be16 be32_to_be16(ovs_be32);
+#endif
+
 #endif /* byte-order.h */
diff --git a/lib/netdev-native-tnl.c b/lib/netdev-native-tnl.c
index e144679..dd7e85f 100644
--- a/lib/netdev-native-tnl.c
+++ b/lib/netdev-native-tnl.c
@@ -387,7 +387,7 @@ parse_gre_header(struct dp_packet *packet,
 }
 
 if (greh->flags & htons(GRE_KEY)) {
-tnl->tun_id = (OVS_FORCE ovs_be64) ((OVS_FORCE 
uint64_t)(get_16aligned_be32(options)) << 32);
+tnl->tun_id = be32_to_be64(get_16aligned_be32(options));
 tnl->flags |= FLOW_TNL_F_KEY;
 options++;
 }
@@ -471,8 +471,7 @@ netdev_gre_build_header(const struct netdev *netdev,
 
 if (tnl_cfg->out_key_present) {
 greh->flags |= htons(GRE_KEY);
-put_16aligned_be32(options, (OVS_FORCE ovs_be32)
-((OVS_FORCE uint64_t) 
params->flow->tunnel.tun_id >> 32));
+put_16aligned_be32(options, be64_to_be32(params->flow->tunnel.tun_id));
 options++;
 }
 
-- 
2.1.3

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

[ovs-dev] [PATCH 3/5] ofp-print: Sort queues before printing in OFPT_QUEUE_GET_CONFIG_REPLY.

2016-05-26 Thread Ben Pfaff

Otherwise the ordering tends to vary across endianness.

Signed-off-by: Ben Pfaff 
---
 lib/ofp-print.c| 60 --
 tests/ofp-print.at |  8 
 tests/ofproto.at   |  4 ++--
 3 files changed, 51 insertions(+), 21 deletions(-)

diff --git a/lib/ofp-print.c b/lib/ofp-print.c
index b21d76f..5e49c60 100644
--- a/lib/ofp-print.c
+++ b/lib/ofp-print.c
@@ -1197,40 +1197,70 @@ print_queue_rate(struct ds *string, const char *name, 
unsigned int rate)
 }
 }
 
+/* qsort comparison function. */
+static int
+compare_queues(const void *a_, const void *b_)
+{
+const struct ofputil_queue_config *a = a_;
+const struct ofputil_queue_config *b = b_;
+
+uint16_t ap = ofp_to_u16(a->port);
+uint16_t bp = ofp_to_u16(b->port);
+if (ap != bp) {
+return ap < bp ? -1 : 1;
+}
+
+uint32_t aq = a->queue;
+uint32_t bq = b->queue;
+return aq < bq ? -1 : aq > bq;
+}
+
 static void
 ofp_print_queue_get_config_reply(struct ds *string,
  const struct ofp_header *oh)
 {
 struct ofpbuf b = ofpbuf_const_initializer(oh, ntohs(oh->length));
-ofp_port_t port = 0;
 
-ds_put_char(string, ' ');
-for (;;) {
-struct ofputil_queue_config queue;
-int retval;
+struct ofputil_queue_config *queues = NULL;
+size_t allocated_queues = 0;
+size_t n = 0;
 
-retval = ofputil_pull_queue_get_config_reply(, );
+int retval = 0;
+for (;;) {
+if (n >= allocated_queues) {
+queues = x2nrealloc(queues, _queues, sizeof *queues);
+}
+retval = ofputil_pull_queue_get_config_reply(, [n]);
 if (retval) {
-if (retval != EOF) {
-ofp_print_error(string, retval);
-}
-ds_chomp(string, ' ');
 break;
 }
+n++;
+}
+
+qsort(queues, n, sizeof *queues, compare_queues);
 
-if (queue.port != port) {
-port = queue.port;
+ds_put_char(string, ' ');
+
+ofp_port_t port = 0;
+for (const struct ofputil_queue_config *q = queues; q < [n]; q++) {
+if (q->port != port) {
+port = q->port;
 
 ds_put_cstr(string, "port=");
 ofputil_format_port(port, string);
 ds_put_char(string, '\n');
 }
 
-ds_put_format(string, "queue %"PRIu32":", queue.queue);
-print_queue_rate(string, "min_rate", queue.min_rate);
-print_queue_rate(string, "max_rate", queue.max_rate);
+ds_put_format(string, "queue %"PRIu32":", q->queue);
+print_queue_rate(string, "min_rate", q->min_rate);
+print_queue_rate(string, "max_rate", q->max_rate);
 ds_put_char(string, '\n');
 }
+
+if (retval != EOF) {
+ofp_print_error(string, retval);
+}
+ds_chomp(string, ' ');
 }
 
 static void
diff --git a/tests/ofp-print.at b/tests/ofp-print.at
index 8e97434..11337b5 100644
--- a/tests/ofp-print.at
+++ b/tests/ofp-print.at
@@ -2565,8 +2565,8 @@ AT_CHECK([ovs-ofctl ofp-print "01 15 00 40 00 00 00 01 \
 00 00 44 44 00 08 00 00 \
 "], [0], [dnl
 OFPT_QUEUE_GET_CONFIG_REPLY (xid=0x1): port=1
-queue 21845: min_rate:50.0% max_rate:75.0%
 queue 17476:
+queue 21845: min_rate:50.0% max_rate:75.0%
 ])
 AT_CLEANUP
 
@@ -2580,8 +2580,8 @@ AT_CHECK([ovs-ofctl ofp-print "02 17 00 40 00 00 00 01 \
 00 00 44 44 00 08 00 00 \
 "], [0], [dnl
 OFPT_QUEUE_GET_CONFIG_REPLY (OF1.1) (xid=0x1): port=1
-queue 21845: min_rate:50.0% max_rate:75.0%
 queue 17476:
+queue 21845: min_rate:50.0% max_rate:75.0%
 ])
 AT_CLEANUP
 
@@ -2595,8 +2595,8 @@ AT_CHECK([ovs-ofctl ofp-print "03 17 00 50 00 00 00 01 \
 00 00 44 44 00 08 00 01 00 10 00 00 00 00 00 00 \
 "], [0], [dnl
 OFPT_QUEUE_GET_CONFIG_REPLY (OF1.2) (xid=0x1): port=1
-queue 21845: min_rate:50.0% max_rate:75.0%
 queue 17476:
+queue 21845: min_rate:50.0% max_rate:75.0%
 ])
 AT_CLEANUP
 
@@ -2610,8 +2610,8 @@ AT_CHECK([ovs-ofctl ofp-print "04 17 00 50 00 00 00 01 \
 00 00 44 44 00 08 00 01 00 10 00 00 00 00 00 00 \
 "], [0], [dnl
 OFPT_QUEUE_GET_CONFIG_REPLY (OF1.3) (xid=0x1): port=1
-queue 21845: min_rate:50.0% max_rate:75.0%
 queue 17476:
+queue 21845: min_rate:50.0% max_rate:75.0%
 ])
 AT_CLEANUP
 
diff --git a/tests/ofproto.at b/tests/ofproto.at
index f8c0d07..1ddee43 100644
--- a/tests/ofproto.at
+++ b/tests/ofproto.at
@@ -294,10 +294,10 @@ add_of_ports br0 1 2
 AT_CHECK([ovs-ofctl -O OpenFlow14 queue-get-config br0 any | strip_xids], [0],
   [OFPST_QUEUE_DESC reply (OF1.4): port=1
 queue 0:
-port=LOCAL
-queue 0:
 port=2
 queue 0:
+port=LOCAL
+queue 0:
 ])
 
 AT_CHECK([ovs-ofctl -O OpenFlow14 queue-get-config br0 1 | strip_xids], [0],
-- 
2.1.3

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

[ovs-dev] [PATCH 1/5] types: Change ofp_port_t from uint16_t to uint32_t.

2016-05-26 Thread Ben Pfaff

This fixes several tests that failed on big-endian systems because "union
flow_in_port" overlays an ofp_port_t and odp_port_t and in some cases it
is not easy to determine which one is in use.

This commit also fixes up a few places where this broke other code.

Signed-off-by: Ben Pfaff 
---
 include/openvswitch/flow.h  |  1 -
 include/openvswitch/types.h | 21 -
 lib/ofp-actions.c   |  2 +-
 utilities/ovs-ofctl.c   |  2 +-
 4 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
index 6f08f3a..03d406b 100644
--- a/include/openvswitch/flow.h
+++ b/include/openvswitch/flow.h
@@ -92,7 +92,6 @@ struct flow {
 ovs_u128 ct_label;  /* Connection label. */
 uint32_t conj_id;   /* Conjunction ID. */
 ofp_port_t actset_output;   /* Output port in action set. */
-uint8_t pad2[2];/* Pad to 64 bits. */
 
 /* L2, Order the same as in the Ethernet header! (64-bit aligned) */
 struct eth_addr dl_dst; /* Ethernet destination address. */
diff --git a/include/openvswitch/types.h b/include/openvswitch/types.h
index 5f3347d..bc94145 100644
--- a/include/openvswitch/types.h
+++ b/include/openvswitch/types.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2010, 2011, 2013, 2014 Nicira, Inc.
+ * Copyright (c) 2010, 2011, 2013, 2014, 2016 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -114,10 +114,21 @@ typedef struct {
 ovs_be32 hi, lo;
 } ovs_32aligned_be64;
 
-/* ofp_port_t represents the port number of a OpenFlow switch.
- * odp_port_t represents the port number on the datapath.
- * ofp11_port_t represents the OpenFlow-1.1 port number. */
-typedef uint16_t OVS_BITWISE ofp_port_t;
+/* Port numbers
+ * 
+ *
+ * None of these types are directly interchangeable, hence the OVS_BITWISE
+ * annotation.
+ *
+ * ofp_port_t is an OpenFlow 1.0 port number.  It uses a 16-bit range, even
+ * though it is a 32-bit type.  This allows it to be overlaid on an odp_port_t
+ * for a few situations where this is useful, e.g. in union flow_in_port.
+ *
+ * ofp11_port_t is an OpenFlow-1.1 port number.
+ *
+ * odp_port_t is a port number within a datapath (e.g. see lib/dpif.h).
+ */
+typedef uint32_t OVS_BITWISE ofp_port_t;
 typedef uint32_t OVS_BITWISE odp_port_t;
 typedef uint32_t OVS_BITWISE ofp11_port_t;
 
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
index b1578c3..69cd3c6 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -1257,7 +1257,7 @@ decode_bundle(bool load, const struct nx_action_bundle 
*nab,
 }
 
 for (i = 0; i < bundle->n_slaves; i++) {
-uint16_t ofp_port = ntohs(((ovs_be16 *)(nab + 1))[i]);
+ofp_port_t ofp_port = ntohs(((ovs_be16 *)(nab + 1))[i]);
 ofpbuf_put(ofpacts, _port, sizeof ofp_port);
 bundle = ofpacts->header;
 }
diff --git a/utilities/ovs-ofctl.c b/utilities/ovs-ofctl.c
index a8116d9..207588b 100644
--- a/utilities/ovs-ofctl.c
+++ b/utilities/ovs-ofctl.c
@@ -3723,7 +3723,7 @@ ofctl_parse_pcap(struct ovs_cmdl_context *ctx)
 ovs_error(error, "%s: read failed", filename);
 }
 
-pkt_metadata_init(>md, ODPP_NONE);
+pkt_metadata_init(>md, u32_to_odp(ofp_to_u16(OFPP_ANY)));
 flow_extract(packet, );
 flow_print(stdout, );
 putchar('\n');
-- 
2.1.3

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

[ovs-dev] [PATCH 0/5] Fixes for big-endian architectures

2016-05-26 Thread Ben Pfaff

These patches fix all of the test failures on big-endian architectures.
I tested on s390x, this machine;
https://db.debian.org/machines.cgi?host=zelenka

Ben Pfaff (5):
  types: Change ofp_port_t from uint16_t to uint32_t.
  netdev-native-tnl: Fix treatment of GRE key on big-endian systems.
  ofp-print: Sort queues before printing in OFPT_QUEUE_GET_CONFIG_REPLY.
  tests: Fix select group test on big-endian systems.
  tests: Avoid endianness sensitivity in MPLS handling test.

 include/openvswitch/flow.h  |  1 -
 include/openvswitch/types.h | 21 
 lib/byte-order.h| 31 ++-
 lib/netdev-native-tnl.c |  5 ++--
 lib/ofp-actions.c   |  2 +-
 lib/ofp-print.c | 60 +
 tests/ofp-print.at  |  8 +++---
 tests/ofproto-dpif.at   | 16 ++--
 tests/ofproto.at|  4 +--
 utilities/ovs-ofctl.c   |  2 +-
 10 files changed, 109 insertions(+), 41 deletions(-)

-- 
2.1.3

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

Re: [ovs-dev] [RFC PATCH] netdev-vport: Enable outer checksum on UDP tunnels by default

2016-05-26 Thread Jesse Gross

On Thu, May 26, 2016 at 4:19 PM, Alexander Duyck  wrote:
> Change the checksum default for UDP based tunnels from true to false and
> allow for csum=false to be used to clear the checksum value on such
> tunnels.
>
> This enables us to use GRO and Rx checksum offloads on incoming frames even
> when the NIC itself is unable to recognize the tunnel based on the UDP port
> number.  For example GENEVE was only recently introduced.  As a result most
> NICs in Linux still don't have support for it.  However, due to the fact
> that we can convert an outer checksum to CHECKSUM_COMPLETE we can get the
> advantage of checksum offload and GRO just based on the outer UDP checksum
> being validated.  As a result we can see throughput significantly increase
> for most cases.
>
> The one case where this might cause performance regression is an
> environment in which a device only supports offloading of UDP tunnels
> without checksums.  This is addressed in kernels 4.7 and newer with the
> introduction of GSO_PARTIAL which will allow most NICs that support
> UDP_TUNNEL segmentation to also support UDP_TUNNEL_CSUM segmentation.  As
> such there should only be a few cases where this can cause a performance
> regression while in the vast majority of cases this will allow for an
> improvement in performance for all NICs that can support UDP checksum
> offload.
>
> Signed-off-by: Alexander Duyck 

My original plan was to do this at the controller level rather than in
OVS itself. I'm still somewhat uncomfortable changing behavior out
from underneath people, especially since we know that in some cases
there will be performance regressions. Within the context of the OVS
project, that would mean changing it in OVN.

I think there is one other thing that we need before this change,
which is backporting the following bug fix to the out of tree OVS
kernel module. Without it, tunnel GRO performs horribly when sending
traffic to VMs. Pravin is in the process of doing this as part of a
larger patch set.

commit a09a4c8dd1ec7f830e1fb9e59eb72bddc965d168
Author: Jesse Gross 
Date:   Sat Mar 19 09:32:02 2016 -0700

tunnels: Remove encapsulation offloads on decap.

If a packet is either locally encapsulated or processed through GRO
it is marked with the offloads that it requires. However, when it is
decapsulated these tunnel offload indications are not removed. This
means that if we receive an encapsulated TCP packet, aggregate it with
GRO, decapsulate, and retransmit the resulting frame on a NIC that does
not support encapsulation, we won't be able to take advantage of hardware
offloads even though it is just a simple TCP packet at this point.

This fixes the problem by stripping off encapsulation offload indications
when packets are decapsulated.

The performance impacts of this bug are significant. In a test where a
Geneve encapsulated TCP stream is sent to a hypervisor, GRO'ed,
decapsulated,
and bridged to a VM performance is improved by 60% (5Gbps->8Gbps) as a
result of avoiding unnecessary segmentation at the VM tap interface.

Reported-by: Ramu Ramamurthy 
Fixes: 68c33163 ("v4 GRE: Add TCP segmentation offload for GRE")
Signed-off-by: Jesse Gross 
Signed-off-by: David S. Miller 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] netlink-notifier: Support multiple groups.

2016-05-26 Thread Jarno Rajahalme

A netlink notifier ('nln') already supports multiple notifiers.  This
patch allows each of these notifiers to subscribe to a different
multicast group.  Sharing a single socket for multiple event types
(each on their own multicast group) provides serialization of events
when reordering of different event types could be problematic.  For
example, if a 'create' event and 'delete' event are on different
netlink multicast group, we may want to process those events in the
order in which kernel issued them, rather than in the order we happen
to check for them.

Moving the multicast group argument from nln_create() to
nln_notifier_create() allows each notifier to specify a different
multicast group.  The parse callback needs to identify the group the
message belonged to by returning the corresponding group number, or 0
when an parse error occurs.

Signed-off-by: Jarno Rajahalme 
---
 lib/netlink-notifier.c | 47 ++
 lib/netlink-notifier.h | 13 ++--
 lib/route-table.c  | 40 +++
 lib/rtnetlink.c| 10 -
 tests/test-netlink-conntrack.c | 32 +---
 5 files changed, 78 insertions(+), 64 deletions(-)

diff --git a/lib/netlink-notifier.c b/lib/netlink-notifier.c
index c2b4f7b..0e4ed9a 100644
--- a/lib/netlink-notifier.c
+++ b/lib/netlink-notifier.c
@@ -32,7 +32,7 @@ VLOG_DEFINE_THIS_MODULE(netlink_notifier);
 
 COVERAGE_DEFINE(nln_changed);
 
-static void nln_report(struct nln *nln, void *change);
+static void nln_report(const struct nln *nln, void *change, int group);
 
 struct nln {
 struct nl_sock *notify_sock; /* Netlink socket. */
@@ -40,7 +40,6 @@ struct nln {
 bool has_run;/* Guard for run and wait functions. */
 
 /* Passed in by nln_create(). */
-int multicast_group; /* Multicast group we listen on. */
 int protocol;/* Protocol passed to nl_sock_create(). */
 nln_parse_func *parse;   /* Message parsing function. */
 void *change;/* Change passed to parse. */
@@ -50,6 +49,7 @@ struct nln_notifier {
 struct nln *nln; /* Parent nln. */
 
 struct ovs_list node;
+int multicast_group; /* Multicast group we listen on. */
 nln_notify_func *cb;
 void *aux;
 };
@@ -60,15 +60,13 @@ struct nln_notifier {
  * Incoming messages will be parsed with 'parse' which will be passed 'change'
  * as an argument. */
 struct nln *
-nln_create(int protocol, int multicast_group, nln_parse_func *parse,
-   void *change)
+nln_create(int protocol, nln_parse_func *parse, void *change)
 {
 struct nln *nln;
 
 nln = xzalloc(sizeof *nln);
 nln->notify_sock = NULL;
 nln->protocol = protocol;
-nln->multicast_group = multicast_group;
 nln->parse = parse;
 nln->change = change;
 nln->has_run = false;
@@ -101,20 +99,17 @@ nln_destroy(struct nln *nln)
  *
  * Returns an initialized nln_notifier if successful, otherwise NULL. */
 struct nln_notifier *
-nln_notifier_create(struct nln *nln, nln_notify_func *cb, void *aux)
+nln_notifier_create(struct nln *nln, int multicast_group, nln_notify_func *cb,
+void *aux)
 {
 struct nln_notifier *notifier;
+int error;
 
 if (!nln->notify_sock) {
 struct nl_sock *sock;
-int error;
 
 error = nl_sock_create(nln->protocol, );
-if (!error) {
-error = nl_sock_join_mcgroup(sock, nln->multicast_group);
-}
 if (error) {
-nl_sock_destroy(sock);
 VLOG_WARN("could not create netlink socket: %s",
   ovs_strerror(error));
 return NULL;
@@ -126,11 +121,21 @@ nln_notifier_create(struct nln *nln, nln_notify_func *cb, 
void *aux)
 nln_run(nln);
 }
 
+error = nl_sock_join_mcgroup(nln->notify_sock, multicast_group);
+if (error) {
+VLOG_WARN("could not join netlink multicast group: %s",
+  ovs_strerror(error));
+return NULL;
+}
+
 notifier = xmalloc(sizeof *notifier);
-ovs_list_push_back(>all_notifiers, >node);
+notifier->multicast_group = multicast_group;
 notifier->cb = cb;
 notifier->aux = aux;
 notifier->nln = nln;
+
+ovs_list_push_back(>all_notifiers, >node);
+
 return notifier;
 }
 
@@ -142,6 +147,8 @@ nln_notifier_destroy(struct nln_notifier *notifier)
 if (notifier) {
 struct nln *nln = notifier->nln;
 
+nl_sock_leave_mcgroup(nln->notify_sock, notifier->multicast_group);
+
 ovs_list_remove(>node);
 if (ovs_list_is_empty(>all_notifiers)) {
 nl_sock_destroy(nln->notify_sock);
@@ -171,11 +178,13 @@ nln_run(struct nln *nln)
 ofpbuf_use_stub(, buf_stub, sizeof buf_stub);
 error = nl_sock_recv(nln->notify_sock, , false);
 if (!error) {
-if (nln->parse(, nln->change)) {
-

[ovs-dev] [RFC PATCH] netdev-vport: Enable outer checksum on UDP tunnels by default

2016-05-26 Thread Alexander Duyck

Change the checksum default for UDP based tunnels from true to false and
allow for csum=false to be used to clear the checksum value on such
tunnels.

This enables us to use GRO and Rx checksum offloads on incoming frames even
when the NIC itself is unable to recognize the tunnel based on the UDP port
number.  For example GENEVE was only recently introduced.  As a result most
NICs in Linux still don't have support for it.  However, due to the fact
that we can convert an outer checksum to CHECKSUM_COMPLETE we can get the
advantage of checksum offload and GRO just based on the outer UDP checksum
being validated.  As a result we can see throughput significantly increase
for most cases.

The one case where this might cause performance regression is an
environment in which a device only supports offloading of UDP tunnels
without checksums.  This is addressed in kernels 4.7 and newer with the
introduction of GSO_PARTIAL which will allow most NICs that support
UDP_TUNNEL segmentation to also support UDP_TUNNEL_CSUM segmentation.  As
such there should only be a few cases where this can cause a performance
regression while in the vast majority of cases this will allow for an
improvement in performance for all NICs that can support UDP checksum
offload.

Signed-off-by: Alexander Duyck 
---
 lib/netdev-vport.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
index 8f2229c45a6d..4c2ec831740a 100644
--- a/lib/netdev-vport.c
+++ b/lib/netdev-vport.c
@@ -432,10 +432,12 @@ set_tunnel_config(struct netdev *dev_, const struct smap 
*args)
 /* Add a default destination port for tunnel ports if none specified. */
 if (!strcmp(type, "geneve")) {
 tnl_cfg.dst_port = htons(GENEVE_DST_PORT);
+tnl_cfg.csum = true;
 }
 
 if (!strcmp(type, "vxlan")) {
 tnl_cfg.dst_port = htons(VXLAN_DST_PORT);
+tnl_cfg.csum = true;
 }
 
 if (!strcmp(type, "lisp")) {
@@ -495,9 +497,7 @@ set_tunnel_config(struct netdev *dev_, const struct smap 
*args)
 } else if (!strcmp(node->key, "dst_port") && needs_dst_port) {
 tnl_cfg.dst_port = htons(atoi(node->value));
 } else if (!strcmp(node->key, "csum") && has_csum) {
-if (!strcmp(node->value, "true")) {
-tnl_cfg.csum = true;
-}
+tnl_cfg.csum = !strcmp(node->value, "true");
 } else if (!strcmp(node->key, "df_default")) {
 if (!strcmp(node->value, "false")) {
 tnl_cfg.dont_fragment = false;

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

Re: [ovs-dev] [PATCH v5] netdev-dpdk: add hotplug support

2016-05-26 Thread Mauricio Vásquez

Hi,

I just sent v6: http://openvswitch.org/pipermail/dev/2016-May/071786.html

On Thu, May 19, 2016 at 9:30 AM, Mauricio Vásquez <
mauricio.vasquezber...@studenti.polito.it> wrote:

>
>
> On Tue, May 17, 2016 at 12:44 AM, Flavio Leitner  wrote:
>
>> On Fri, May 13, 2016 at 10:25:41PM +0200, Mauricio Vasquez B wrote:
>> > In order to use dpdk ports in ovs they have to be bound to a DPDK
>> > compatible driver before ovs is started.
>> >
>> > This patch adds the possibility to hotplug (or hot-unplug) a device
>> > after ovs has been started. The implementation adds two appctl commands:
>> > netdev-dpdk/port-attach and netdev-dpdk/port-detach
>> >
>> > After the user attaches a new device, it has to be added to a bridge
>> > using the add-port command, similarly, before detaching a device,
>> > it has to be removed using the del-port command.
>> >
>> > Signed-off-by: Mauricio Vasquez B <
>> mauricio.vasquezber...@studenti.polito.it>
>>
>> The patch looks good, but it didn't work for me with VFIO (it's
>> not supported by the DPDK hotplug framework).  Since the doc
>> includes instructions to use VFIO, should we add a note for the
>> lack of hotplug support?
>>
>>
> Yes, we should. I'll wait few days to see if there is more feedback and
> I'll send a new version including that note.
>
>
>> The attach/detach operations seem to work with uio_pci_generic,
>> but it doesn't move packets.  The interface statistics shows
>> only 'errs' increasing a lot and few 'drops'.
>>
>> Kernel: 4.5.0+
>> OVS: master (b396293a) + patch
>> DPDK: 16.04
>> Drivers: vfio-pci or uio_pci_generic
>> Hardware: 82599ES
>>
>>
> I tried uio_pci_generic in the following conditions without any problem.
>
> Kernel: 3.19.0-32-generic
> OVS: master(d640a7e1) + patch
> DPDK: 16.04
> Hardware: X540-AT2
>
>
>> Do you know if there are patches/plans to support that with VFIO or
>> uio_pci_generic?
>>
>
> I am not aware of any plans for it.
>
> Thanks for reviewing Flavio!
>
>
>> fbl
>>
>>
>> > ---
>> > v5:
>> >  - use two appctl commands instead of a single one
>> >  - rebase to master
>> > v4:
>> >  - fix typo in commit message
>> >  - remove unnecessary whitespace change in INSTALL.DPDK.md
>> > v3:
>> >  - create dpdk_port_attach and dpdk_port_detach functions
>> >  - modify mutex locking order
>> > v2:
>> >  - use rte_eth_dev_is_valid_port() to check if a port is valid
>> >  INSTALL.DPDK.md   |  24 +
>> >  NEWS  |   1 +
>> >  lib/netdev-dpdk.c | 101
>> ++
>> >  3 files changed, 119 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
>> > index 93f92e4..8d5a0e0 100644
>> > --- a/INSTALL.DPDK.md
>> > +++ b/INSTALL.DPDK.md
>> > @@ -267,6 +267,29 @@ Using the DPDK with ovs-vswitchd:
>> > For more details regarding egress-policer parameters please refer
>> to the
>> > vswitch.xml.
>> >
>> > +9. Port Hotplug
>> > +
>> > +   Ovs supports port hotplugging, it allows to use ports that were not
>> bound
>> > +   to DPDK when vswitchd was started.
>> > +   In order to attach a port, it has to be bound to DPDK using the
>> > +   dpdk_nic_bind.py script:
>> > +
>> > +   `$DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio :01:00.0`
>> > +
>> > +   Then it can be attached to OVS:
>> > +
>> > +   `ovs-appctl netdev-dpdk/port-attach :01:00.0`
>> > +
>> > +   At this point, the user can create a ovs port using the add-port
>> command.
>> > +
>> > +   It is also possible to detach a port from ovs, the user has to
>> remove the
>> > +   port using the del-port command, then it can be detached using:
>> > +
>> > +   `ovs-appctl netdev-dpdk/port-detach dpdk0`
>> > +
>> > +   This feature is not supported by all the NICs, please refer to the
>> > +   [DPDK Port Hotplug Framework] in order to get more information.
>> > +
>> >  Performance Tuning:
>> >  ---
>> >
>> > @@ -999,3 +1022,4 @@ Please report problems to b...@openvswitch.org.
>> >  [INSTALL.md]:INSTALL.md
>> >  [DPDK Linux GSG]:
>> http://www.dpdk.org/doc/guides/linux_gsg/build_dpdk.html#binding-and-unbinding-network-ports-to-from-the-igb-uioor-vfio-modules
>> >  [DPDK Docs]: http://dpdk.org/doc
>> > +[DPDK Port Hotplug Framework]:
>> http://dpdk.org/doc/guides/prog_guide/port_hotplug_framework.html
>> > diff --git a/NEWS b/NEWS
>> > index 4e81cad..d89d9a7 100644
>> > --- a/NEWS
>> > +++ b/NEWS
>> > @@ -32,6 +32,7 @@ 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.
>> > + * Port Hotplug is now supported.
>> > - ovs-benchmark: This utility has been removed due to lack of use
>> and
>> >   bitrot.
>> > - ovs-appctl:
>> > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>> > index af86d19..6159a60 100644
>> > --- a/lib/netdev-dpdk.c
>> > +++ b/lib/netdev-dpdk.c
>> > @@ -630,7 +630,7 @@

[ovs-dev] [PATCH v6] netdev-dpdk: add hotplug support

2016-05-26 Thread Mauricio Vasquez B

In order to use dpdk ports in ovs they have to be bound to a DPDK
compatible driver before ovs is started.

This patch adds the possibility to hotplug (or hot-unplug) a device
after ovs has been started. The implementation adds two appctl commands:
netdev-dpdk/port-attach and netdev-dpdk/port-detach

After the user attaches a new device, it has to be added to a bridge
using the add-port command, similarly, before detaching a device,
it has to be removed using the del-port command.

Signed-off-by: Mauricio Vasquez B 
Tested-by: ian.sto...@intel.com
---
v6:
 - add explicit comment about supporting VFIO
 - rebase to master
v5:
 - use two appctl commands instead of a single one
 - rebase to master
v4:
 - fix typo in commit message
 - remove unnecessary whitespace change in INSTALL.DPDK.md
v3:
 - create dpdk_port_attach and dpdk_port_detach functions
 - modify mutex locking order
v2:
 - use rte_eth_dev_is_valid_port() to check if a port is valid
 INSTALL.DPDK.md   |  25 ++
 NEWS  |   1 +
 lib/netdev-dpdk.c | 101 ++
 3 files changed, 120 insertions(+), 7 deletions(-)

diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
index 68735cc..948957b 100644
--- a/INSTALL.DPDK.md
+++ b/INSTALL.DPDK.md
@@ -286,6 +286,30 @@ Using the DPDK with ovs-vswitchd:
 
For more details regarding ingress-policer see the vswitch.xml.
 
+10. Port Hotplug
+
+   Ovs supports port hotplugging, it allows to use ports that were not bound
+   to DPDK when vswitchd was started.
+   In order to attach a port, it has to be bound to DPDK using the
+   dpdk_nic_bind.py script:
+
+   `$DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio :01:00.0`
+
+   Then it can be attached to OVS:
+
+   `ovs-appctl netdev-dpdk/port-attach :01:00.0`
+
+   At this point, the user can create a ovs port using the add-port command.
+
+   It is also possible to detach a port from ovs, the user has to remove the
+   port using the del-port command, then it can be detached using:
+
+   `ovs-appctl netdev-dpdk/port-detach dpdk0`
+
+   This feature is not supported with VFIO and could not work with some NICs,
+   please refer to the [DPDK Port Hotplug Framework] in order to get more
+   information.
+
 Performance Tuning:
 ---
 
@@ -1018,3 +1042,4 @@ Please report problems to b...@openvswitch.org.
 [INSTALL.md]:INSTALL.md
 [DPDK Linux GSG]: 
http://www.dpdk.org/doc/guides/linux_gsg/build_dpdk.html#binding-and-unbinding-network-ports-to-from-the-igb-uioor-vfio-modules
 [DPDK Docs]: http://dpdk.org/doc
+[DPDK Port Hotplug Framework]: 
http://dpdk.org/doc/guides/prog_guide/port_hotplug_framework.html
diff --git a/NEWS b/NEWS
index ba201cf..4018836 100644
--- a/NEWS
+++ b/NEWS
@@ -33,6 +33,7 @@ Post-v2.5.0
arguments. Additional arguments can be passed via the dpdk-extra
entry.
  * Add ingress policing functionality.
+ * Port Hotplug is now supported.
- ovs-benchmark: This utility has been removed due to lack of use and
  bitrot.
- ovs-appctl:
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 6cae930..f5a8678 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -649,7 +649,7 @@ dpdk_eth_dev_init(struct netdev_dpdk *dev) 
OVS_REQUIRES(dpdk_mutex)
 int diag;
 int n_rxq, n_txq;
 
-if (dev->port_id < 0 || dev->port_id >= rte_eth_dev_count()) {
+if (!rte_eth_dev_is_valid_port(dev->port_id)) {
 return ENODEV;
 }
 
@@ -2231,6 +2231,83 @@ netdev_dpdk_set_admin_state(struct unixctl_conn *conn, 
int argc,
 unixctl_command_reply(conn, "OK");
 }
 
+static void
+netdev_dpdk_port_attach(struct unixctl_conn *conn, int argc OVS_UNUSED,
+const char *argv[], void *aux OVS_UNUSED)
+{
+int ret;
+char response[128];
+uint8_t port_id;
+
+ovs_mutex_lock(_mutex);
+
+ret = rte_eth_dev_attach(argv[1], _id);
+if (ret < 0) {
+snprintf(response, sizeof(response),
+ "Error attaching device '%s'", argv[1]);
+ovs_mutex_unlock(_mutex);
+unixctl_command_reply_error(conn, response);
+return;
+}
+
+snprintf(response, sizeof(response),
+ "Device '%s' has been attached as 'dpdk%d'", argv[1], port_id);
+
+ovs_mutex_unlock(_mutex);
+unixctl_command_reply(conn, response);
+}
+
+static void
+netdev_dpdk_port_detach(struct unixctl_conn *conn, int argc OVS_UNUSED,
+const char *argv[], void *aux OVS_UNUSED)
+{
+int ret;
+char response[128];
+unsigned int parsed_port;
+uint8_t port_id;
+char devname[RTE_ETH_NAME_MAX_LEN];
+
+ovs_mutex_lock(_mutex);
+
+ret = dpdk_dev_parse_name(argv[1], "dpdk", _port);
+if (ret) {
+snprintf(response, sizeof(response),
+ "'%s' is not a valid port", argv[1]);
+goto error;
+}
+
+port_id = parsed_port;
+
+struct netdev *netdev = netdev_from_name(argv[1]);
+

Re: [ovs-dev] [PATCH 0/6] create tunnel devices using rtnetlink interface

2016-05-26 Thread Thadeu Lima de Souza Cascardo

On Thu, May 26, 2016 at 02:01:05PM -0700, Jesse Gross wrote:
> On Thu, May 26, 2016 at 1:34 PM, Thadeu Lima de Souza Cascardo
>  wrote:
> > One thing that may be seen as a regression is the MTU of those devices. It 
> > won't
> > be IP_MAX_MTU as in latest upstream, but supporting older kernels restrict 
> > us to
> > use 1500 for VXLAN and GENEVE.
> 
> Is it possible to detect this and continue using the compat code on
> those kernels? (I think it's a pretty narrow range of kernels that
> support metadata mode on tunnels but not MTU adjustment.) As you say,
> it's otherwise a regression from where we currently are as far as
> jumbo frames go and also results in different behavior between tunnel
> types and kernel versions.

We could try setting a larger MTU and, if that fails, revert to compat code.
There still is going to be a range of kernel versions where this problem happens
(between 4.3 and 4.5, I guess). The other issue is that the code introduced by
David Wrang adds a non-strict option that only OVS compatibility code can use.
That means we cannot use IP_MAX_MTU but a slightly smaller value. I don't think
that would be a problem, though.

I would still like to see any other comments on the patchset before I send a v2
fixing that.

Thanks, Jesse.

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

Re: [ovs-dev] [PATCH 0/6] create tunnel devices using rtnetlink interface

2016-05-26 Thread Jesse Gross

On Thu, May 26, 2016 at 1:34 PM, Thadeu Lima de Souza Cascardo
 wrote:
> One thing that may be seen as a regression is the MTU of those devices. It 
> won't
> be IP_MAX_MTU as in latest upstream, but supporting older kernels restrict us 
> to
> use 1500 for VXLAN and GENEVE.

Is it possible to detect this and continue using the compat code on
those kernels? (I think it's a pretty narrow range of kernels that
support metadata mode on tunnels but not MTU adjustment.) As you say,
it's otherwise a regression from where we currently are as far as
jumbo frames go and also results in different behavior between tunnel
types and kernel versions.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v4] ovn-northd: logical router icmp response should not care about inport

2016-05-26 Thread Flavio Fernandes

When responding to icmp echo requests (aka ping) packets, the logical
router should not restrict responses based on the inport.

Example diagram:

vm: IP1.1 (subnet1)
logical_router: IP1.2 (subnet1) and IP2.2 (subnet2)

   vm ---[subnet1]--- logical_router ---[subnet2]
   

vm should be able to ping , even though it is an address
of a subnet that can only be reached through L3 routing.

Reference to the mailing list thread:
http://openvswitch.org/pipermail/discuss/2016-May/021172.html

---
Changes v1->v2:
  - Add unit test.

Changes v2->v3:
  - Code review feedback from Russell Bryant
  - Fix comment section on how vm can ping ip2.2

Changes v3->v4:
  - Rebase
  - Resolve open discussion on ttl: it is a non-issue
Thanks Ben P and Darrell B!
Ref: http://openvswitch.org/pipermail/dev/2016-May/071773.html

Signed-off-by: Flavio Fernandes 
---
 ovn/northd/ovn-northd.c |   9 ++-
 tests/ovn.at| 174 
 2 files changed, 180 insertions(+), 3 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 44e9430..987601f 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -1892,11 +1892,14 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 free(match);
 
 /* ICMP echo reply.  These flows reply to ICMP echo requests
- * received for the router's IP address. */
+ * received for the router's IP address. Since packets only
+ * get here as part of the logical router datapath, the inport
+ * (i.e. the incoming locally attached net) does not matter.
+ * The ip.ttl also does not matter (RFC1812 section 4.2.2.9) */
 match = xasprintf(
-"inport == %s && (ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") && "
+"(ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") && "
 "icmp4.type == 8 && icmp4.code == 0",
-op->json_key, IP_ARGS(op->ip), IP_ARGS(op->bcast));
+IP_ARGS(op->ip), IP_ARGS(op->bcast));
 char *actions = xasprintf(
 "ip4.dst = ip4.src; "
 "ip4.src = "IP_FMT"; "
diff --git a/tests/ovn.at b/tests/ovn.at
index e6ac1d7..0572f64 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -2611,3 +2611,177 @@ OVS_APP_EXIT_AND_WAIT([ovs-vswitchd])
 OVS_APP_EXIT_AND_WAIT([ovsdb-server])
 
 AT_CLEANUP
+
+AT_SETUP([ovn -- icmp_reply: 1 HVs, 2 LSs, 1 lport/LS, 1 LR])
+AT_KEYWORDS([router-icmp-reply])
+AT_SKIP_IF([test $HAVE_PYTHON = no])
+ovn_start
+
+# Logical network:
+# One LR - R1 has switch ls1 (191.168.1.0/24) connected to it,
+# and has switch ls2 (172.16.1.0/24) connected to it.
+
+ovn-nbctl create Logical_Router name=R1
+
+ovn-nbctl lswitch-add ls1
+ovn-nbctl lswitch-add ls2
+
+# Connect ls1 to R1
+ovn-nbctl -- --id=@lrp create Logical_Router_port name=ls1 \
+network=192.168.1.1/24 mac=\"00:00:00:01:02:f1\" -- add Logical_Router R1 \
+ports @lrp -- lport-add ls1 rp-ls1
+
+ovn-nbctl set Logical_port rp-ls1 type=router options:router-port=ls1 \
+addresses=\"00:00:00:01:02:f1\"
+
+# Connect ls2 to R1
+ovn-nbctl -- --id=@lrp create Logical_Router_port name=ls2 \
+network=172.16.1.1/24 mac=\"00:00:00:01:02:f2\" -- add Logical_Router R1 \
+ports @lrp -- lport-add ls2 rp-ls2
+
+ovn-nbctl set Logical_port rp-ls2 type=router options:router-port=ls2 \
+addresses=\"00:00:00:01:02:f2\"
+
+# Create logical port ls1-lp1 in ls1
+ovn-nbctl lport-add ls1 ls1-lp1 \
+-- lport-set-addresses ls1-lp1 "00:00:00:01:02:03 192.168.1.2"
+
+# Create logical port ls2-lp1 in ls2
+ovn-nbctl lport-add ls2 ls2-lp1 \
+-- lport-set-addresses ls2-lp1 "00:00:00:01:02:04 172.16.1.2"
+
+# Create one hypervisor and create OVS ports corresponding to logical ports.
+net_add n1
+
+sim_add hv1
+as hv1
+ovs-vsctl add-br br-phys
+ovn_attach n1 br-phys 192.168.0.1
+ovs-vsctl -- add-port br-int vif1 -- \
+set interface vif1 external-ids:iface-id=ls1-lp1 \
+options:tx_pcap=hv1/vif1-tx.pcap \
+options:rxq_pcap=hv1/vif1-rx.pcap \
+ofport-request=1
+
+ovs-vsctl -- add-port br-int vif2 -- \
+set interface vif2 external-ids:iface-id=ls2-lp1 \
+options:tx_pcap=hv1/vif2-tx.pcap \
+options:rxq_pcap=hv1/vif2-rx.pcap \
+ofport-request=1
+
+
+# Allow some time for ovn-northd and ovn-controller to catch up.
+# XXX This should be more systematic.
+sleep 1
+
+
+ip_to_hex() {
+printf "%02x%02x%02x%02x" "$@"
+}
+trim_zeros() {
+sed 's/\(00\)\{1,\}$//'
+}
+for i in 1 2; do
+: > vif$i.expected
+done
+# test_ipv4_icmp_request INPORT ETH_SRC ETH_DST IPV4_SRC IPV4_DST IP_CHKSUM 
ICMP_CHKSUM [EXP_IP_CHKSUM EXP_ICMP_CHKSUM]
+#
+# Causes a packet to be received on INPORT.  The packet is an ICMPv4
+# request with ETH_SRC, ETH_DST, IPV4_SRC and IPV4_DST as specified.  If 
EXP_IP_CHKSUM
+# is provided, then it should be the ip checksum of the packet responded;
+# otherwise no reply is expected.
+# In the absence of an ip checksum calculation

[ovs-dev] [PATCH 6/6] dpif-netlink: add GENEVE creation support

2016-05-26 Thread Thadeu Lima de Souza Cascardo

Creates GENEVE devices using rtnetlink and tunnel metadata. If the kernel does
not support tunnel metadata, it will return EINVAL because of the missing ID and
REMOTE attributes.

This was tested on kernels 4.2.3, 4.3.6 and 4.4.9. All of them worked with the
system traffic test "datapath - ping over geneve tunnel".

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 lib/dpif-netlink.c | 83 ++
 1 file changed, 83 insertions(+)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 7e30341..5a694b3 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -970,6 +970,12 @@ netdev_gre_destroy(const char *name)
 return netdev_linux_destroy(name);
 }
 
+static int
+netdev_geneve_destroy(const char *name)
+{
+return netdev_linux_destroy(name);
+}
+
 /*
  * On some older systems, these enums are not defined.
  */
@@ -988,8 +994,21 @@ netdev_gre_destroy(const char *name)
 #define IFLA_GRE_COLLECT_METADATA 18
 #endif
 
+#ifndef IFLA_GENEVE_MAX
+#define IFLA_GENEVE_MAX 0
+#define IFLA_GENEVE_PORT 5
+#endif
+
+#if IFLA_GENEVE_MAX < 6
+#define IFLA_GENEVE_COLLECT_METADATA 6
+#endif
+#if IFLA_GENEVE_MAX < 10
+#define IFLA_GENEVE_UDP_ZERO_CSUM6_RX 10
+#endif
+
 #define MTU_MAX_VXLAN 1500
 #define MTU_MAX_GRE (0xfff8 - ETH_HEADER_LEN - 4 - IP_HEADER_LEN)
+#define MTU_MAX_GENEVE 1500
 
 static int
 netdev_vxlan_create(struct netdev *netdev)
@@ -1152,6 +1171,56 @@ netdev_gre_create(struct netdev *netdev)
 return err;
 }
 
+static int
+netdev_geneve_create(struct netdev *netdev)
+{
+int err;
+struct ofpbuf request, *reply;
+size_t linkinfo_off, infodata_off;
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+const char *name = netdev_vport_get_dpif_port(netdev,
+  namebuf, sizeof namebuf);
+struct ifinfomsg *ifinfo;
+const struct netdev_tunnel_config *tnl_cfg;
+tnl_cfg = netdev_get_tunnel_config(netdev);
+if (!tnl_cfg) { /* or assert? */
+return EINVAL;
+}
+
+ofpbuf_init(, 0);
+nl_msg_put_nlmsghdr(, 0, RTM_NEWLINK,
+NLM_F_REQUEST | NLM_F_ACK | NLM_F_CREATE);
+ifinfo = ofpbuf_put_zeros(, sizeof(struct ifinfomsg));
+ifinfo->ifi_change = ifinfo->ifi_flags = IFF_UP;
+nl_msg_put_string(, IFLA_IFNAME, name);
+nl_msg_put_u32(, IFLA_MTU, MTU_MAX_GENEVE);
+linkinfo_off = nl_msg_start_nested(, IFLA_LINKINFO);
+nl_msg_put_string(, IFLA_INFO_KIND, "geneve");
+infodata_off = nl_msg_start_nested(, IFLA_INFO_DATA);
+nl_msg_put_flag(, IFLA_GENEVE_COLLECT_METADATA);
+nl_msg_put_u8(, IFLA_GENEVE_UDP_ZERO_CSUM6_RX, 1);
+nl_msg_put_be16(, IFLA_GENEVE_PORT, tnl_cfg->dst_port);
+nl_msg_end_nested(, infodata_off);
+nl_msg_end_nested(, linkinfo_off);
+
+err = nl_transact(NETLINK_ROUTE, , );
+
+if (!err) {
+ofpbuf_uninit(reply);
+}
+
+/*
+ * Linux versions older than 4.3 will return EINVAL in case the GENEVE_ID 
is
+ * not set, which is sufficient to verify COLLECT_METADATA is supported.
+ */
+if (err == EINVAL) {
+err = EOPNOTSUPP;
+}
+
+ofpbuf_uninit();
+return err;
+}
+
 #else
 
 static int
@@ -1167,6 +1236,12 @@ netdev_gre_create(struct netdev *netdev OVS_UNUSED)
 }
 
 static int
+netdev_geneve_create(struct netdev *netdev OVS_UNUSED)
+{
+return EOPNOTSUPP;
+}
+
+static int
 netdev_vxlan_destroy(const char *name OVS_UNUSED)
 {
 return EOPNOTSUPP;
@@ -1178,6 +1253,12 @@ netdev_gre_destroy(const char *name OVS_UNUSED)
 return EOPNOTSUPP;
 }
 
+static int
+netdev_geneve_destroy(const char *name OVS_UNUSED)
+{
+return EOPNOTSUPP;
+}
+
 #endif
 
 static int
@@ -1193,6 +1274,7 @@ dpif_netlink_port_create(struct netdev *netdev)
 case OVS_VPORT_TYPE_GRE:
 return netdev_gre_create(netdev);
 case OVS_VPORT_TYPE_GENEVE:
+return netdev_geneve_create(netdev);
 case OVS_VPORT_TYPE_NETDEV:
 case OVS_VPORT_TYPE_INTERNAL:
 case OVS_VPORT_TYPE_LISP:
@@ -1214,6 +1296,7 @@ dpif_netlink_port_destroy(const char *name, const char 
*type)
 case OVS_VPORT_TYPE_GRE:
 return netdev_gre_destroy(name);
 case OVS_VPORT_TYPE_GENEVE:
+return netdev_geneve_destroy(name);
 case OVS_VPORT_TYPE_NETDEV:
 case OVS_VPORT_TYPE_INTERNAL:
 case OVS_VPORT_TYPE_LISP:
-- 
2.5.5

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

[ovs-dev] [PATCH 1/6] route-table: if device is not there, route is still parseable

2016-05-26 Thread Thadeu Lima de Souza Cascardo

Do not return failure to parse a route if device has been removed before we are
able to parse the route. That prevents "received bad netlink message" warnings
on the log.

This can be reproduced by simply removing interfaces.

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 lib/route-table.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/route-table.c b/lib/route-table.c
index 2d095dc..d837d98 100644
--- a/lib/route-table.c
+++ b/lib/route-table.c
@@ -252,7 +252,11 @@ route_table_parse(struct ofpbuf *buf, struct 
route_table_msg *change)
 
 VLOG_DBG_RL(, "Could not find interface name[%u]: %s",
 rta_oif, ovs_strerror(error));
-return false;
+if (error == ENXIO) {
+change->relevant = false;
+} else {
+return false;
+}
 }
 }
 
-- 
2.5.5

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

[ovs-dev] [PATCH 5/6] dpif-netlink: add GRE creation support

2016-05-26 Thread Thadeu Lima de Souza Cascardo

Creates GRE devices using rtnetlink and tunnel metadata. If the kernel does
not support tunnel metadata, it will return EEXIST because of the fallback
tunnel. However, on kernels between v3.10 and v3.12, it will not. So, we need to
verify the created tunnel has the tunnel metadata attribute.

This was tested on kernels 4.2.3, 4.3.6, 4.4.9 and RHEL 3.10 based. All of them
worked with the system traffic test "datapath - ping over gre tunnel". Also
tested on a 3.10 based kernel without the fix for the existing fallback tunnel.
That is, the kernel would not return EEXIST. Yet, the test works fine.

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 lib/dpif-netlink.c | 134 +
 1 file changed, 134 insertions(+)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 89fd903..7e30341 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -963,6 +964,12 @@ netdev_vxlan_destroy(const char *name)
 return netdev_linux_destroy(name);
 }
 
+static int
+netdev_gre_destroy(const char *name)
+{
+return netdev_linux_destroy(name);
+}
+
 /*
  * On some older systems, these enums are not defined.
  */
@@ -977,7 +984,12 @@ netdev_vxlan_destroy(const char *name)
 #define IFLA_VXLAN_COLLECT_METADATA 25
 #endif
 
+#if IFLA_GRE_MAX < 18
+#define IFLA_GRE_COLLECT_METADATA 18
+#endif
+
 #define MTU_MAX_VXLAN 1500
+#define MTU_MAX_GRE (0xfff8 - ETH_HEADER_LEN - 4 - IP_HEADER_LEN)
 
 static int
 netdev_vxlan_create(struct netdev *netdev)
@@ -1032,6 +1044,114 @@ netdev_vxlan_create(struct netdev *netdev)
 return err;
 }
 
+/*
+ * On some Linux versions, creating the device with IFLA_GRE_COLLECT_METADATA
+ * will succeed, even though that attribute is not supported. We need to verify
+ * the device has been created with that attribute. In case it has not, we
+ * destroy it and use the compat code.
+ */
+static int
+netdev_gre_verify(const char *name)
+{
+int err;
+struct ofpbuf request, *reply;
+struct ifinfomsg *ifmsg;
+
+static const struct nl_policy rtlink_policy[] = {
+[IFLA_LINKINFO] = { .type = NL_A_NESTED },
+};
+static const struct nl_policy linkinfo_policy[] = {
+[IFLA_INFO_KIND] = { .type = NL_A_STRING },
+[IFLA_INFO_DATA] = { .type = NL_A_NESTED },
+};
+static const struct nl_policy gre_policy[] = {
+[IFLA_GRE_COLLECT_METADATA] = { .type = NL_A_FLAG },
+};
+
+ofpbuf_init(, 0);
+nl_msg_put_nlmsghdr(, 0, RTM_GETLINK,
+NLM_F_REQUEST);
+ofpbuf_put_zeros(, sizeof(struct ifinfomsg));
+nl_msg_put_string(, IFLA_IFNAME, name);
+
+err = nl_transact(NETLINK_ROUTE, , );
+if (!err) {
+struct nlattr *rtlink[ARRAY_SIZE(rtlink_policy)];
+struct nlattr *linkinfo[ARRAY_SIZE(linkinfo_policy)];
+struct nlattr *gre[ARRAY_SIZE(gre_policy)];
+
+err = EINVAL;
+ifmsg = ofpbuf_at(reply, NLMSG_HDRLEN, sizeof *ifmsg);
+if (nl_policy_parse(reply, NLMSG_HDRLEN + sizeof *ifmsg,
+rtlink_policy, rtlink, ARRAY_SIZE(rtlink_policy))) {
+if (nl_parse_nested(rtlink[IFLA_LINKINFO], linkinfo_policy,
+linkinfo, ARRAY_SIZE(linkinfo_policy)) &&
+!strcmp(nl_attr_get_string(linkinfo[IFLA_INFO_KIND]), "gre")) {
+if (nl_parse_nested(linkinfo[IFLA_INFO_DATA], gre_policy, gre,
+ARRAY_SIZE(gre_policy)) &&
+nl_attr_get_flag(gre[IFLA_GRE_COLLECT_METADATA])) {
+err = 0;
+}
+}
+}
+ofpbuf_uninit(reply);
+}
+ofpbuf_uninit();
+return err;
+}
+
+static int
+netdev_gre_create(struct netdev *netdev)
+{
+int err;
+struct ofpbuf request, *reply;
+size_t linkinfo_off, infodata_off;
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+const char *name = netdev_vport_get_dpif_port(netdev,
+  namebuf, sizeof namebuf);
+struct ifinfomsg *ifinfo;
+const struct netdev_tunnel_config *tnl_cfg;
+tnl_cfg = netdev_get_tunnel_config(netdev);
+if (!tnl_cfg) { /* or assert? */
+return EINVAL;
+}
+
+ofpbuf_init(, 0);
+nl_msg_put_nlmsghdr(, 0, RTM_NEWLINK,
+NLM_F_REQUEST | NLM_F_ACK | NLM_F_CREATE);
+ifinfo = ofpbuf_put_zeros(, sizeof(struct ifinfomsg));
+ifinfo->ifi_change = ifinfo->ifi_flags = IFF_UP;
+nl_msg_put_string(, IFLA_IFNAME, name);
+nl_msg_put_u32(, IFLA_MTU, MTU_MAX_GRE);
+linkinfo_off = nl_msg_start_nested(, IFLA_LINKINFO);
+nl_msg_put_string(, IFLA_INFO_KIND, "gretap");
+infodata_off = nl_msg_start_nested(, IFLA_INFO_DATA);
+nl_msg_put_flag(, IFLA_GRE_COLLECT_METADATA);
+nl_msg_end_nested(, infodata_off);
+nl_msg_end_nested(, linkinfo_off);
+
+err =

[ovs-dev] [PATCH 4/6] dpif-netlink: add VXLAN creation support

2016-05-26 Thread Thadeu Lima de Souza Cascardo

Creates VXLAN devices using rtnetlink and tunnel metadata. If the kernel does
not support tunnel metadata, it will return EINVAL because of the missing VNI
attribute.

This was tested on kernels 4.2.3, 4.3.6, 4.4.9 and RHEL-based 3.10. All of them
worked with the system traffic test "datapath - ping over vxlan tunnel".

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 lib/dpif-netlink.c | 121 -
 1 file changed, 120 insertions(+), 1 deletion(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index b624118..89fd903 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -24,7 +24,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -931,6 +933,121 @@ dpif_netlink_port_add_compat(struct dpif_netlink *dpif, 
struct netdev *netdev,
 
 }
 
+#ifdef __linux__
+
+static int
+netdev_linux_destroy(const char *name)
+{
+int err;
+struct ofpbuf request, *reply;
+
+ofpbuf_init(, 0);
+nl_msg_put_nlmsghdr(, 0, RTM_DELLINK,
+NLM_F_REQUEST | NLM_F_ACK);
+ofpbuf_put_zeros(, sizeof(struct ifinfomsg));
+nl_msg_put_string(, IFLA_IFNAME, name);
+
+err = nl_transact(NETLINK_ROUTE, , );
+
+if (!err) {
+ofpbuf_uninit(reply);
+}
+
+ofpbuf_uninit();
+return err;
+}
+
+static int
+netdev_vxlan_destroy(const char *name)
+{
+return netdev_linux_destroy(name);
+}
+
+/*
+ * On some older systems, these enums are not defined.
+ */
+
+#ifndef IFLA_VXLAN_MAX
+#define IFLA_VXLAN_MAX 0
+#define IFLA_VXLAN_PORT 15
+#endif
+#if IFLA_VXLAN_MAX < 20
+#define IFLA_VXLAN_UDP_ZERO_CSUM6_RX 20
+#define IFLA_VXLAN_GBP 23
+#define IFLA_VXLAN_COLLECT_METADATA 25
+#endif
+
+#define MTU_MAX_VXLAN 1500
+
+static int
+netdev_vxlan_create(struct netdev *netdev)
+{
+int err;
+struct ofpbuf request, *reply;
+size_t linkinfo_off, infodata_off;
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+const char *name = netdev_vport_get_dpif_port(netdev,
+  namebuf, sizeof namebuf);
+struct ifinfomsg *ifinfo;
+const struct netdev_tunnel_config *tnl_cfg;
+tnl_cfg = netdev_get_tunnel_config(netdev);
+if (!tnl_cfg) { /* or assert? */
+return EINVAL;
+}
+
+ofpbuf_init(, 0);
+nl_msg_put_nlmsghdr(, 0, RTM_NEWLINK,
+NLM_F_REQUEST | NLM_F_ACK | NLM_F_CREATE);
+ifinfo = ofpbuf_put_zeros(, sizeof(struct ifinfomsg));
+ifinfo->ifi_change = ifinfo->ifi_flags = IFF_UP;
+nl_msg_put_string(, IFLA_IFNAME, name);
+nl_msg_put_u32(, IFLA_MTU, MTU_MAX_VXLAN);
+linkinfo_off = nl_msg_start_nested(, IFLA_LINKINFO);
+nl_msg_put_string(, IFLA_INFO_KIND, "vxlan");
+infodata_off = nl_msg_start_nested(, IFLA_INFO_DATA);
+nl_msg_put_u8(, IFLA_VXLAN_COLLECT_METADATA, 1);
+nl_msg_put_u8(, IFLA_VXLAN_UDP_ZERO_CSUM6_RX, 1);
+if (tnl_cfg->exts & (1 << OVS_VXLAN_EXT_GBP)) {
+nl_msg_put_flag(, IFLA_VXLAN_GBP);
+}
+nl_msg_put_be16(, IFLA_VXLAN_PORT, tnl_cfg->dst_port);
+nl_msg_end_nested(, infodata_off);
+nl_msg_end_nested(, linkinfo_off);
+
+err = nl_transact(NETLINK_ROUTE, , );
+
+if (!err) {
+ofpbuf_uninit(reply);
+}
+
+/*
+ * Linux versions older than 4.3 will return EINVAL in case the VID is not
+ * set, which is sufficient to verify COLLECT_METADATA is supported.
+ */
+if (err == EINVAL) {
+err = EOPNOTSUPP;
+}
+
+ofpbuf_uninit();
+return err;
+}
+
+#else
+
+static int
+netdev_vxlan_create(struct netdev *netdev OVS_UNUSED)
+{
+return EOPNOTSUPP;
+}
+
+static int
+netdev_vxlan_destroy(const char *name OVS_UNUSED)
+{
+return EOPNOTSUPP;
+}
+
+#endif
+
 static int
 dpif_netlink_port_query__(const struct dpif_netlink *dpif, odp_port_t port_no,
   const char *port_name, struct dpif_port *dpif_port);
@@ -940,6 +1057,7 @@ dpif_netlink_port_create(struct netdev *netdev)
 {
 switch (netdev_to_ovs_vport_type(netdev_get_type(netdev))) {
 case OVS_VPORT_TYPE_VXLAN:
+return netdev_vxlan_create(netdev);
 case OVS_VPORT_TYPE_GRE:
 case OVS_VPORT_TYPE_GENEVE:
 case OVS_VPORT_TYPE_NETDEV:
@@ -955,10 +1073,11 @@ dpif_netlink_port_create(struct netdev *netdev)
 }
 
 static int
-dpif_netlink_port_destroy(const char *name OVS_UNUSED, const char *type)
+dpif_netlink_port_destroy(const char *name, const char *type)
 {
 switch (netdev_to_ovs_vport_type(type)) {
 case OVS_VPORT_TYPE_VXLAN:
+return netdev_vxlan_destroy(name);
 case OVS_VPORT_TYPE_GRE:
 case OVS_VPORT_TYPE_GENEVE:
 case OVS_VPORT_TYPE_NETDEV:
-- 
2.5.5

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

[ovs-dev] [PATCH 2/6] netdev: get device type from vport prefix if not found

2016-05-26 Thread Thadeu Lima de Souza Cascardo

If we cannot find the device type because it's not opened yet, check if it uses
a reserved prefix for a vport type and return that type.

Since these names are reserved, we can assume this is the right type.

This is important when we are querying the datapath right after vswitch has
started and using the right type will be even more important when we add support
to creating tunnel ports with rtnetlink.

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 lib/netdev.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/lib/netdev.c b/lib/netdev.c
index 4be806d..f9325d7 100644
--- a/lib/netdev.c
+++ b/lib/netdev.c
@@ -281,6 +281,24 @@ netdev_enumerate_types(struct sset *types)
 }
 }
 
+static const char *
+netdev_vport_type_from_name(const char *name)
+{
+struct netdev_registered_class *rc;
+const char *type;
+ovs_mutex_lock(_class_mutex);
+CMAP_FOR_EACH (rc, cmap_node, _classes) {
+const char *dpif_port = netdev_vport_class_get_dpif_port(rc->class);
+if (dpif_port && !strncmp(name, dpif_port, strlen(dpif_port))) {
+type = rc->class->type;
+ovs_mutex_unlock(_class_mutex);
+return type;
+}
+}
+ovs_mutex_unlock(_class_mutex);
+return NULL;
+}
+
 /* Check that the network device name is not the same as any of the registered
  * vport providers' dpif_port name (dpif_port is NULL if the vport provider
  * does not define it) or the datapath internal port name (e.g. ovs-system).
@@ -1762,6 +1780,7 @@ netdev_get_type_from_name(const char *name)
 struct netdev *dev = netdev_from_name(name);
 const char *type = dev ? netdev_get_type(dev) : NULL;
 netdev_close(dev);
+type = type ?: netdev_vport_type_from_name(name);
 return type;
 }
 
-- 
2.5.5

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

[ovs-dev] [PATCH 0/6] create tunnel devices using rtnetlink interface

2016-05-26 Thread Thadeu Lima de Souza Cascardo

This series adds support for the creation of tunnels using the rtnetlink
interface. This will open the possibility for new features and flags on those
vports without the need to change vport compatibility code.

Support for STT and LISP have not been added because these are not upstream yet,
so we don't know how the interface will be like upstream. And there are no
features in the current drivers right now we could make use of.

One thing that may be seen as a regression is the MTU of those devices. It won't
be IP_MAX_MTU as in latest upstream, but supporting older kernels restrict us to
use 1500 for VXLAN and GENEVE.

Thadeu Lima de Souza Cascardo (6):
  route-table: if device is not there, route is still parseable
  netdev: get device type from vport prefix if not found
  dpif-netlink: break code to add compat and non-compat vports
  dpif-netlink: add VXLAN creation support
  dpif-netlink: add GRE creation support
  dpif-netlink: add GENEVE creation support

 lib/dpif-netlink.c | 529 -
 lib/netdev.c   |  19 ++
 lib/route-table.c  |   6 +-
 3 files changed, 503 insertions(+), 51 deletions(-)

-- 
2.5.5

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

[ovs-dev] [PATCH 3/6] dpif-netlink: break code to add compat and non-compat vports

2016-05-26 Thread Thadeu Lima de Souza Cascardo

The vport type for adding tunnels is now compatibility code and any new features
from tunnels must configure the tunnel as an interface using the tunnel metadata
support.

In order to be able to add those tunnels, we need to add code to create the
tunnels and add them as NETDEV vports. And when there is no support to create
them, we need to use the compatibility code and add them as tunnel vports.

When removing those tunnels, we need to remove the interfaces as well, and
detecting the right type might be important, at least to distinguish the tunnel
vports that we should remove and the interfaces that we shouldn't.

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 lib/dpif-netlink.c | 195 +++--
 1 file changed, 144 insertions(+), 51 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 9bff3a8..b624118 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -780,10 +780,8 @@ get_vport_type(const struct dpif_netlink_vport *vport)
 }
 
 static enum ovs_vport_type
-netdev_to_ovs_vport_type(const struct netdev *netdev)
+netdev_to_ovs_vport_type(const char *type)
 {
-const char *type = netdev_get_type(netdev);
-
 if (!strcmp(type, "tap") || !strcmp(type, "system")) {
 return OVS_VPORT_TYPE_NETDEV;
 } else if (!strcmp(type, "internal")) {
@@ -804,19 +802,14 @@ netdev_to_ovs_vport_type(const struct netdev *netdev)
 }
 
 static int
-dpif_netlink_port_add__(struct dpif_netlink *dpif, struct netdev *netdev,
+dpif_netlink_port_add__(struct dpif_netlink *dpif, const char *name,
+enum ovs_vport_type type,
+struct ofpbuf *options,
 odp_port_t *port_nop)
 OVS_REQ_WRLOCK(dpif->upcall_lock)
 {
-const struct netdev_tunnel_config *tnl_cfg;
-char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
-const char *name = netdev_vport_get_dpif_port(netdev,
-  namebuf, sizeof namebuf);
-const char *type = netdev_get_type(netdev);
 struct dpif_netlink_vport request, reply;
 struct ofpbuf *buf;
-uint64_t options_stub[64 / 8];
-struct ofpbuf options;
 struct nl_sock **socksp = NULL;
 uint32_t *upcall_pids;
 int error = 0;
@@ -831,52 +824,19 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, struct 
netdev *netdev,
 dpif_netlink_vport_init();
 request.cmd = OVS_VPORT_CMD_NEW;
 request.dp_ifindex = dpif->dp_ifindex;
-request.type = netdev_to_ovs_vport_type(netdev);
-if (request.type == OVS_VPORT_TYPE_UNSPEC) {
-VLOG_WARN_RL(_rl, "%s: cannot create port `%s' because it has "
- "unsupported type `%s'",
- dpif_name(>dpif), name, type);
-vport_del_socksp(dpif, socksp);
-return EINVAL;
-}
+request.type = type;
 request.name = name;
 
-if (request.type == OVS_VPORT_TYPE_NETDEV) {
-#ifdef _WIN32
-/* XXX : Map appropiate Windows handle */
-#else
-netdev_linux_ethtool_set_flag(netdev, ETH_FLAG_LRO, "LRO", false);
-#endif
-}
-
-tnl_cfg = netdev_get_tunnel_config(netdev);
-if (tnl_cfg && (tnl_cfg->dst_port != 0 || tnl_cfg->exts)) {
-ofpbuf_use_stack(, options_stub, sizeof options_stub);
-if (tnl_cfg->dst_port) {
-nl_msg_put_u16(, OVS_TUNNEL_ATTR_DST_PORT,
-   ntohs(tnl_cfg->dst_port));
-}
-if (tnl_cfg->exts) {
-size_t ext_ofs;
-int i;
-
-ext_ofs = nl_msg_start_nested(, OVS_TUNNEL_ATTR_EXTENSION);
-for (i = 0; i < 32; i++) {
-if (tnl_cfg->exts & (1 << i)) {
-nl_msg_put_flag(, i);
-}
-}
-nl_msg_end_nested(, ext_ofs);
-}
-request.options = options.data;
-request.options_len = options.size;
-}
-
 request.port_no = *port_nop;
 upcall_pids = vport_socksp_to_pids(socksp, dpif->n_handlers);
 request.n_upcall_pids = socksp ? dpif->n_handlers : 1;
 request.upcall_pids = upcall_pids;
 
+if (options) {
+request.options = options->data;
+request.options_len = options->size;
+}
+
 error = dpif_netlink_vport_transact(, , );
 if (!error) {
 *port_nop = reply.port_no;
@@ -916,6 +876,127 @@ exit:
 }
 
 static int
+dpif_netlink_port_add_compat(struct dpif_netlink *dpif, struct netdev *netdev,
+ odp_port_t *port_nop)
+OVS_REQ_WRLOCK(dpif->upcall_lock)
+{
+const struct netdev_tunnel_config *tnl_cfg;
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+const char *name = netdev_vport_get_dpif_port(netdev,
+  namebuf, sizeof namebuf);
+const char *type = netdev_get_type(netdev);
+uint64_t options_stub[64 / 8];
+struct ofpbuf options;
+enum ovs_vport_type ovs_type;
+
+ovs_type =

Re: [ovs-dev] [PATCH v3] ovn-northd: logical router icmp response should not care about inport

2016-05-26 Thread Flaviof

On Thu, May 26, 2016 at 2:05 PM, Ben Pfaff  wrote:

> On Thu, May 26, 2016 at 12:39:36PM -0400, Flavio Fernandes wrote:
> > To be discussed:
> >
> > One caveat here is that ttl should be decremented before vm
> > reaches , assuming the ping packet is coming from
> > a remote subnet.
> >
> > In short, we ideally would have the match augmented to look
> > like this.
> >
> >   "(inport == %s || ip.ttl > 1) && (ip4.dst == "IP_FMT" || ip4.dst ==
> "IP_FMT") && ...
> >
> > Afer talking to Russel [1] it seems that we have either a bug or
> > a known limitation on how a match on ip.ttl can be used with the
> > greater than operator. I tried a couple of tweaks [2] against a
> > test ping with ttl 10 and concluded that both
> > negation and greater than are not working as expected. Assuming
> > ip.ttl should be supported in the match, there are 3 issues that
> > should be followed upon, which may be outside the scope of this
> > patch:
> >   1) fix/support negation and greater than operator for ip.ttl
> >   2) update doc on supported matches (ovn-sb);
> >   3) expand unit tests to verify ip.ttl in match
>
> Inequalities are intentionally unsupported for ip.ttl.  You can see this
> pretty clearly from ovstest output:
>
> $ echo 'ip.ttl == 1' | tests/ovstest test-ovn parse-expr
> ip.ttl == 0x1
> $ echo 'ip.ttl > 1' | tests/ovstest test-ovn parse-expr
> Only == and != operators may be used with nominal field ip.ttl.
>
>
Very cool! Thanks for mentioning about 'tests/ovstest test-ovn parse-expr'.
Do you think it would be a good idea to have this ttl expression added to
ovn.at ? If so, I can do it in a separate patch.



> The proximate reason for this is that ip.ttl is a nominal field.  That's
> because the OpenFlow field for IP TTL (NXM_NX_IP_TTL) is nonmaskable;
> that is, at the OpenFlow layer, OVS rejects attempts to match on a
> subset of bits in the TTL.
>
> It would be easy to change both of these decisions.  Making
> NXM_NX_IP_TTL maskable is a one-line change to a comment (!), and making
> ip.ttl ordinal would be equally trivial.
>
> But I made NXM_NX_IP_TTL nonmaskable for good reason.  That is because
> inequality matches are expensive.  The comparison "ip.ttl > 1" needs 7
> OpenFlow flows, each of which tests only one bit.  This can be a big
> deal because each of those flows ends up in a separate hash table in the
> classifier, adding 7 separate hash table lookups to any classifier
> search, which is inefficient.
>
> That's why the existing ip.ttl checks instead use "ip.ttl == {0,1}",
> which only uses 2 OpenFlow flows, both of which can fit in the same
> classifier lookup table.
>
>
Make sense. Just for giggles I did a little experiment using my vanilla
linux distro
as a router to see if it cared about ttl when responging to pings in a
similar
situation.

To my surprise -- kinda not -- the linux router code was happy to reply to
that
ping without prejudice. ;)  See below [pingTest] for the steps and output.

With that, I'm now proposing that we skip doing anything
beyond the removal of the inport from the logical flow match. If you do not
agree, please make it known on the next patch I submit for this.


> So, it's better if we can use a design that can use a higher-priority
> flow to handle too-low TTLs as a special case, then handle the common
> case with a lower priority flow.
>

And you already added that [ttldis]. My only point was that this is done
later
in the router datapath processing, so the packets destined to the router
are the
only ones that do not have the ttl check.

** update **: Darrell pointed out the excerpt in RFC that indicates that
ttl checking
is not to happen when packet is destined to the router. With that, there is
no
further discussion required on this particular topic.


> I may be microoptimizing.  I am open to that discussion.
>

Not at all, blp! And this is all very good info. I really appreciate it.

Best,

-- flaviof

[ttldis]:
https://github.com/openvswitch/ovs/commit/9975d7beb36ab3aadfd07c9d566f8d3d1d340fc4#diff-2c35162acf6ad144624954fdc4c3d9f4R1348

[pingTest]:
https://gist.github.com/bee26f82113ff9dd2715c6451e19718c

vm ---(192.168.50.0/24)--- rtr ---(192.168.111.0/24)

vm: 192.168.50.200
rtr (port1): 192.168.50.254
rtr (port2): 192.168.111.254

vagrant@ubuntu:~$ sudo ip route 192.168.111.254 255.255.255.255
192.168.50.254

vagrant@ubuntu:~$ sudo tcpdump -n -vvv -i eth1 &
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535
bytes

vagrant@ubuntu:~$ ping -t 1 -c 1 -I eth1 192.168.111.254 ; echo "--X-X--"
PING 192.168.111.254 (192.168.111.254) from 192.168.50.200 eth1: 56(84)
bytes of data.
64 bytes from 192.168.111.254: icmp_seq=1 ttl=64 time=0.526 ms

--- 192.168.111.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.526/0.526/0.526/0.000 ms
--X-X--
vagrant@ubuntu:~$ 19:53:21.606126 IP (tos 0x0, ttl 1, id 21870, offset 0,
flags [DF], proto ICMP (1), length 84)

Re: [ovs-dev] [PATCH v2] ovn-northd: logical router icmp response should not care about inport

2016-05-26 Thread Flaviof

On Thu, May 26, 2016 at 4:00 PM, Darrell Ball  wrote:

>
>
> On Wed, May 25, 2016 at 9:40 PM, Flavio Fernandes 
> wrote:
>
>> When responding to icmp echo requests (aka ping) packets, the logical
>> router should not restrict responses based on the inport.
>>
>> Example diagram:
>>
>> vm: IP1.1 (subnet1)
>> logical_router: IP1.2 (subnet1) and IP2.2 (subnet2)
>>
>>vm ---[subnet1]--- logical_router ---[subnet2]
>>
>>
>> vm should be able to ping , even though it is an address
>> of a subnet that can only be reached through L3 routing.
>>
>> Reference to the mailing list thread:
>> http://openvswitch.org/pipermail/discuss/2016-May/021172.html
>>
>> ---
>> Changes v1->v2:
>>   - Add unit test.
>>
>> To be discussed:
>>
>> One caveat here is that ttl should be decremented before vm
>> reaches  and that logic is not invoked until later
>> in the pipeline. Further work may be necessary in order
>> to make ip.ttl part of the match in the logical table, so
>> pings from the non-local subnet are only responded if ttl > 1.
>> As far as I can tell, the match on logical flows currently does
>> not handle ip.ttl.
>>
>> In short, instead of simply removing the inport match in the icmp rule,
>> we could add a second rule that would do something like:
>>
>>   "inport == %s && (ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") && ... <=
>> priority 90
>>   "ip.ttl > 1 && (ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") && ... <=
>> priority 90-X
>>
>
>
> These pings are destined to one of a router's own IP addresses; i.e. local
> to the router.
>
> The router is not forwarding the original ICMP request since an ICMP reply
> is a separate packet from the ICMP request.
>
> The below is an excerpt from RFC 1812 and it also references RFC 791.
>
> 4.2.2.9 Time to Live: RFC 791 Section 3.2
> .
> .
> Note in particular that a router MUST NOT check the TTL of a packet
> except when forwarding it.
> .
> .
> A router MUST NOT discard a datagram just because it was received
> with a TTL equal to zero or one; if it is to the router and otherwise
> valid, the router must attempt to receive it.
>
>
That 100% puts away my concern. Thanks Darrell!
I'll submit a revised patch that incorporates this.

-- flaviof


>
>
>>
>> Signed-off-by: Flavio Fernandes 
>> ---
>>  ovn/northd/ovn-northd.c |   8 ++-
>>  tests/ovn.at| 173
>> 
>>  2 files changed, 178 insertions(+), 3 deletions(-)
>>
>> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
>> index 44e9430..68decbf 100644
>> --- a/ovn/northd/ovn-northd.c
>> +++ b/ovn/northd/ovn-northd.c
>> @@ -1892,11 +1892,13 @@ build_lrouter_flows(struct hmap *datapaths,
>> struct hmap *ports,
>>  free(match);
>>
>>  /* ICMP echo reply.  These flows reply to ICMP echo requests
>> - * received for the router's IP address. */
>> + * received for the router's IP address. Since packets only
>> + * get here as part of the logical router datapath, the inport
>> + * (i.e. the incoming locally attached net) does not matter. */
>>  match = xasprintf(
>> -"inport == %s && (ip4.dst == "IP_FMT" || ip4.dst ==
>> "IP_FMT") && "
>> +"(ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") && "
>>  "icmp4.type == 8 && icmp4.code == 0",
>> -op->json_key, IP_ARGS(op->ip), IP_ARGS(op->bcast));
>> +IP_ARGS(op->ip), IP_ARGS(op->bcast));
>>  char *actions = xasprintf(
>>  "ip4.dst = ip4.src; "
>>  "ip4.src = "IP_FMT"; "
>> diff --git a/tests/ovn.at b/tests/ovn.at
>> index e6ac1d7..8cd3677 100644
>> --- a/tests/ovn.at
>> +++ b/tests/ovn.at
>> @@ -2611,3 +2611,176 @@ OVS_APP_EXIT_AND_WAIT([ovs-vswitchd])
>>  OVS_APP_EXIT_AND_WAIT([ovsdb-server])
>>
>>  AT_CLEANUP
>> +
>> +AT_SETUP([ovn -- icmp_reply: 1 HVs, 2 LSs, 1 lport/LS, 1 LR])
>> +AT_KEYWORDS([router-icmp-reply])
>> +AT_SKIP_IF([test $HAVE_PYTHON = no])
>> +ovn_start
>> +
>> +# Logical network:
>> +# One LR - R1 has switch ls1 (191.168.1.0/24) connected to it,
>> +# and has switch ls2 (172.16.1.0/24) connected to it.
>> +
>> +ovn-nbctl create Logical_Router name=R1
>> +
>> +ovn-nbctl lswitch-add ls1
>> +ovn-nbctl lswitch-add ls2
>> +
>> +# Connect ls1 to R1
>> +ovn-nbctl -- --id=@lrp create Logical_Router_port name=ls1 \
>> +network=192.168.1.1/24 mac=\"00:00:00:01:02:f1\" -- add Logical_Router
>> R1 \
>> +ports @lrp -- lport-add ls1 rp-ls1
>> +
>> +ovn-nbctl set Logical_port rp-ls1 type=router options:router-port=ls1 \
>> +addresses=\"00:00:00:01:02:f1\"
>> +
>> +# Connect ls2 to R1
>> +ovn-nbctl -- --id=@lrp create Logical_Router_port name=ls2 \
>> +network=172.16.1.1/24 mac=\"00:00:00:01:02:f2\" -- add Logical_Router
>> R1 \
>> +ports @lrp -- lport-add ls2 rp-ls2
>> +
>> +ovn-nbctl set Logical_port rp-ls2 type=router options:router-port=ls2 \
>> +addresses=\"00:00:00:01:02:f2\"

Re: [ovs-dev] [PATCH v2] ovn-northd: logical router icmp response should not care about inport

2016-05-26 Thread Darrell Ball

On Wed, May 25, 2016 at 9:40 PM, Flavio Fernandes 
wrote:

> When responding to icmp echo requests (aka ping) packets, the logical
> router should not restrict responses based on the inport.
>
> Example diagram:
>
> vm: IP1.1 (subnet1)
> logical_router: IP1.2 (subnet1) and IP2.2 (subnet2)
>
>vm ---[subnet1]--- logical_router ---[subnet2]
>
>
> vm should be able to ping , even though it is an address
> of a subnet that can only be reached through L3 routing.
>
> Reference to the mailing list thread:
> http://openvswitch.org/pipermail/discuss/2016-May/021172.html
>
> ---
> Changes v1->v2:
>   - Add unit test.
>
> To be discussed:
>
> One caveat here is that ttl should be decremented before vm
> reaches  and that logic is not invoked until later
> in the pipeline. Further work may be necessary in order
> to make ip.ttl part of the match in the logical table, so
> pings from the non-local subnet are only responded if ttl > 1.
> As far as I can tell, the match on logical flows currently does
> not handle ip.ttl.
>
> In short, instead of simply removing the inport match in the icmp rule,
> we could add a second rule that would do something like:
>
>   "inport == %s && (ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") && ... <=
> priority 90
>   "ip.ttl > 1 && (ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") && ... <=
> priority 90-X
>


These pings are destined to one of a router's own IP addresses; i.e. local
to the router.

The router is not forwarding the original ICMP request since an ICMP reply
is a separate packet from the ICMP request.

The below is an excerpt from RFC 1812 and it also references RFC 791.

4.2.2.9 Time to Live: RFC 791 Section 3.2
.
.
Note in particular that a router MUST NOT check the TTL of a packet
except when forwarding it.
.
.
A router MUST NOT discard a datagram just because it was received
with a TTL equal to zero or one; if it is to the router and otherwise
valid, the router must attempt to receive it.




>
> Signed-off-by: Flavio Fernandes 
> ---
>  ovn/northd/ovn-northd.c |   8 ++-
>  tests/ovn.at| 173
> 
>  2 files changed, 178 insertions(+), 3 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 44e9430..68decbf 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -1892,11 +1892,13 @@ build_lrouter_flows(struct hmap *datapaths, struct
> hmap *ports,
>  free(match);
>
>  /* ICMP echo reply.  These flows reply to ICMP echo requests
> - * received for the router's IP address. */
> + * received for the router's IP address. Since packets only
> + * get here as part of the logical router datapath, the inport
> + * (i.e. the incoming locally attached net) does not matter. */
>  match = xasprintf(
> -"inport == %s && (ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT")
> && "
> +"(ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") && "
>  "icmp4.type == 8 && icmp4.code == 0",
> -op->json_key, IP_ARGS(op->ip), IP_ARGS(op->bcast));
> +IP_ARGS(op->ip), IP_ARGS(op->bcast));
>  char *actions = xasprintf(
>  "ip4.dst = ip4.src; "
>  "ip4.src = "IP_FMT"; "
> diff --git a/tests/ovn.at b/tests/ovn.at
> index e6ac1d7..8cd3677 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -2611,3 +2611,176 @@ OVS_APP_EXIT_AND_WAIT([ovs-vswitchd])
>  OVS_APP_EXIT_AND_WAIT([ovsdb-server])
>
>  AT_CLEANUP
> +
> +AT_SETUP([ovn -- icmp_reply: 1 HVs, 2 LSs, 1 lport/LS, 1 LR])
> +AT_KEYWORDS([router-icmp-reply])
> +AT_SKIP_IF([test $HAVE_PYTHON = no])
> +ovn_start
> +
> +# Logical network:
> +# One LR - R1 has switch ls1 (191.168.1.0/24) connected to it,
> +# and has switch ls2 (172.16.1.0/24) connected to it.
> +
> +ovn-nbctl create Logical_Router name=R1
> +
> +ovn-nbctl lswitch-add ls1
> +ovn-nbctl lswitch-add ls2
> +
> +# Connect ls1 to R1
> +ovn-nbctl -- --id=@lrp create Logical_Router_port name=ls1 \
> +network=192.168.1.1/24 mac=\"00:00:00:01:02:f1\" -- add Logical_Router
> R1 \
> +ports @lrp -- lport-add ls1 rp-ls1
> +
> +ovn-nbctl set Logical_port rp-ls1 type=router options:router-port=ls1 \
> +addresses=\"00:00:00:01:02:f1\"
> +
> +# Connect ls2 to R1
> +ovn-nbctl -- --id=@lrp create Logical_Router_port name=ls2 \
> +network=172.16.1.1/24 mac=\"00:00:00:01:02:f2\" -- add Logical_Router R1
> \
> +ports @lrp -- lport-add ls2 rp-ls2
> +
> +ovn-nbctl set Logical_port rp-ls2 type=router options:router-port=ls2 \
> +addresses=\"00:00:00:01:02:f2\"
> +
> +# Create logical port ls1-lp1 in ls1
> +ovn-nbctl lport-add ls1 ls1-lp1 \
> +-- lport-set-addresses ls1-lp1 "00:00:00:01:02:03 192.168.1.2"
> +
> +# Create logical port ls2-lp1 in ls2
> +ovn-nbctl lport-add ls2 ls2-lp1 \
> +-- lport-set-addresses ls2-lp1 "00:00:00:01:02:04 172.16.1.2"
> +
> +# Create one hypervisor and create OVS ports

Re: [ovs-dev] copy

2016-05-26 Thread Robin Brock

Dear dev,

With reference to the telephonic conversation, I am sending a copy of document 
attached to this mail.

Hope to hear from you soon .


Regards,

Trinity Industries, Inc.
Robin Brock
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 11/12] datapath: compat: Add support for IPv6 UDP tunnel segmentation.

2016-05-26 Thread pravin shelar

On Wed, May 25, 2016 at 4:36 PM, Jesse Gross  wrote:
> On Wed, May 4, 2016 at 4:35 PM, Pravin B Shelar  wrote:
>> diff --git a/datapath/linux/compat/include/net/ipv6.h 
>> b/datapath/linux/compat/include/net/ipv6.h
>> index 5cc5b6e..6faafb0 100644
>> --- a/datapath/linux/compat/include/net/ipv6.h
>> +++ b/datapath/linux/compat/include/net/ipv6.h
>> @@ -81,4 +81,9 @@ static inline __be32 ip6_make_flowinfo(unsigned int 
>> tclass, __be32 flowlabel)
>> return htonl(tclass << IPV6_TCLASS_SHIFT) | flowlabel;
>>  }
>>
>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(3,18,0)
>> +#define ip6_local_out rpl_ip6_local_out
>> +int rpl_ip6_local_out(struct sk_buff *skb);
>> +#endif
>> +
>>  #endif
>
> The IPv4 version is defined in gso.h and the implementations of both
> functions are in gso.c. Should we move both definitions to one header
> or another?
>
I will move ipv4 function declarations to ipv4 header. I think we can
keep all definitions in gso.c.

>> +void ovs_udp_csum_gso(struct sk_buff *skb)
>> +{
>> +   int udp_offset = skb_transport_offset(skb);
>> +
>> +   ovs_udp_gso(skb);
>> +
>> +   if (!OVS_GSO_CB(skb)->ipv6) {
>> +   struct iphdr *iph = ip_hdr(skb);
>> +
>> +   /* csum segment if tunnel sets skb with csum. The cleanest 
>> way
>> +* to do this just to set it up from scratch. */
>> +   skb->ip_summed = CHECKSUM_NONE;
>> +   udp_set_csum(false, skb, iph->saddr, iph->daddr,
>> +   skb->len - udp_offset);
>> +#if IS_ENABLED(CONFIG_IPV6)
>> +   } else {
>> +   struct ipv6hdr *ip6h;
>> +
>> +   ip6h = ipv6_hdr(skb);
>> +   udp6_set_csum(false, skb, >saddr, >daddr,
>> + skb->len - udp_offset);
>
> It seems like there is an inconsistency between IPv4 and IPv6 when it
> comes to setting skb->ip_summed = CHECKSUM_NONE. Presumably, this
> isn't really necessary since we are passing in 0 for feature flags to
> skb_gso_segment().

ok. I will fix the inconsistency.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] copy

2016-05-26 Thread Brooks Rosales

Dear dev,

With reference to the telephonic conversation, I am sending a copy of document 
attached to this mail.

Hope to hear from you soon .


Regards,

McCormick & Company, Incorporated
Brooks Rosales
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] copy

2016-05-26 Thread Stella Bishop

Dear dev,

With reference to the telephonic conversation, I am sending a copy of document 
attached to this mail.

Hope to hear from you soon .


Regards,

ARC Document Solutions, Inc.
Stella Bishop
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Question on L3 Logical Router in vtep-emulator

2016-05-26 Thread Darrell Ball

On Thu, May 26, 2016 at 9:14 AM, Kyle Mestery  wrote:

> On Thu, May 26, 2016 at 10:46 AM, Guru Shetty  wrote:
> >
> >>
> >>
> >> OK, I'm going to play with this a bit. I was mostly interested in
> >> feedback from others. We're interested in this approach and so if we
> >> take the patch up does it stand a chance of merging?
> >
> >
> > If I remember correctly, the main problem was around ARP handling when
> the
> > destination's mac address is not known. Who would do the job that
> > ovn-controller currently does for OVN? If a clean solution is proposed,
> then
> > I can't think of any reasons why it can't be merged.
> >
> Your last comments said you also didn't appreciate the overall
> approach, which is what I was referring to.
>
> Either way, yes, the ARP handling needs to be solved, and VTEP schema
> likely needs some work around NAT as you say.


One advantage of exploring the VTEP schema for L3 gateway here is it is one
formal way to remove
some assumptive constraints associated with the existing OVN datapaths.

You don't even have to stay within the bounds of the VTEP schema.



> I'm going to revive this
> patch and see what can be done here.
>
> Thanks!
> Kyle
>
> >>
> >>
> >> >>
> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Thanks!
> >> >> >> Kyle
> >> >> >>
> >> >> >> [1] https://patchwork.ozlabs.org/patch/553435/
> >> >> >> ___
> >> >> >> dev mailing list
> >> >> >> dev@openvswitch.org
> >> >> >> http://openvswitch.org/mailman/listinfo/dev
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
> ___
> 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 v3] ovn-northd: logical router icmp response should not care about inport

2016-05-26 Thread Ben Pfaff

On Thu, May 26, 2016 at 12:39:36PM -0400, Flavio Fernandes wrote:
> To be discussed:
> 
> One caveat here is that ttl should be decremented before vm
> reaches , assuming the ping packet is coming from
> a remote subnet.
> 
> In short, we ideally would have the match augmented to look
> like this.
> 
>   "(inport == %s || ip.ttl > 1) && (ip4.dst == "IP_FMT" || ip4.dst == 
> "IP_FMT") && ...
> 
> Afer talking to Russel [1] it seems that we have either a bug or
> a known limitation on how a match on ip.ttl can be used with the
> greater than operator. I tried a couple of tweaks [2] against a
> test ping with ttl 10 and concluded that both
> negation and greater than are not working as expected. Assuming
> ip.ttl should be supported in the match, there are 3 issues that
> should be followed upon, which may be outside the scope of this
> patch:
>   1) fix/support negation and greater than operator for ip.ttl
>   2) update doc on supported matches (ovn-sb);
>   3) expand unit tests to verify ip.ttl in match

Inequalities are intentionally unsupported for ip.ttl.  You can see this
pretty clearly from ovstest output:

$ echo 'ip.ttl == 1' | tests/ovstest test-ovn parse-expr
ip.ttl == 0x1
$ echo 'ip.ttl > 1' | tests/ovstest test-ovn parse-expr
Only == and != operators may be used with nominal field ip.ttl.

The proximate reason for this is that ip.ttl is a nominal field.  That's
because the OpenFlow field for IP TTL (NXM_NX_IP_TTL) is nonmaskable;
that is, at the OpenFlow layer, OVS rejects attempts to match on a
subset of bits in the TTL.

It would be easy to change both of these decisions.  Making
NXM_NX_IP_TTL maskable is a one-line change to a comment (!), and making
ip.ttl ordinal would be equally trivial.

But I made NXM_NX_IP_TTL nonmaskable for good reason.  That is because
inequality matches are expensive.  The comparison "ip.ttl > 1" needs 7
OpenFlow flows, each of which tests only one bit.  This can be a big
deal because each of those flows ends up in a separate hash table in the
classifier, adding 7 separate hash table lookups to any classifier
search, which is inefficient.

That's why the existing ip.ttl checks instead use "ip.ttl == {0,1}",
which only uses 2 OpenFlow flows, both of which can fit in the same
classifier lookup table.

So, it's better if we can use a design that can use a higher-priority
flow to handle too-low TTLs as a special case, then handle the common
case with a lower priority flow.

I may be microoptimizing.  I am open to that discussion.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH branch-2.4] tests: Fix lookup segmentation test.

2016-05-26 Thread Joe Stringer

On 26 May 2016 at 10:36, Ben Pfaff  wrote:
> On Thu, May 26, 2016 at 10:27:09AM -0700, Joe Stringer wrote:
>> This test has been failing since IGMP megaflow matching was fixed.
>> Update the test to fix the build.
>>
>> Fixes: aeb14ab7f6cd ("ofproto-dpif-xlate: Fix IGMP megaflow matching.")
>> Signed-off-by: Joe Stringer 
>
> Oops.  I thought I caught all of those.  Thank you.
>
> Acked-by: Ben Pfaff 

There was just this one on branch-2.4 so you almost had them all:)

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

Re: [ovs-dev] [PATCH branch-2.4] tests: Fix lookup segmentation test.

2016-05-26 Thread Ben Pfaff

On Thu, May 26, 2016 at 10:27:09AM -0700, Joe Stringer wrote:
> This test has been failing since IGMP megaflow matching was fixed.
> Update the test to fix the build.
> 
> Fixes: aeb14ab7f6cd ("ofproto-dpif-xlate: Fix IGMP megaflow matching.")
> Signed-off-by: Joe Stringer 

Oops.  I thought I caught all of those.  Thank you.

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

[ovs-dev] [PATCH] vswitch.xml: Document interface name length restrictions.

2016-05-26 Thread Ben Pfaff

Signed-off-by: Ben Pfaff 
---
 vswitchd/vswitch.xml | 59 +---
 1 file changed, 47 insertions(+), 12 deletions(-)

diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index 0c9e60c..0958fe4 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -620,13 +620,18 @@
 
   
 
-  Bridge identifier.  Should be alphanumeric and no more than about 8
-  bytes long.  Must be unique among the names of ports, interfaces, and
-  bridges on a host.
+  Bridge identifier.  Must be unique among the names of ports,
+  interfaces, and bridges on a host.
 
 
 
-  Forward and backward slashes are prohibited in bridge names.
+  The name must be alphanumeric and must not contain forward or
+  backward slashes.  The name of a bridge is also the name of an  (and a ) within the bridge, so
+  the restrictions on the  column
+  in the  table, particularly on length, also
+  apply to bridge names.  Refer to the documentation for  names for details.
 
   
 
@@ -1241,10 +1246,13 @@
 part of the port's  members.
 
 
-  Port name.  Should be alphanumeric and no more than about 8
-  bytes long.  May be the same as the interface name, for
-  non-bonded ports.  Must otherwise be unique among the names of
-  ports, interfaces, and bridges on a host.
+  Port name.  For a non-bonded port, this should be the same as its
+  interface's name.  Port names must otherwise be unique among the names of
+  ports, interfaces, and bridges on a host.  Because port and interfaces
+  names are usually the same, the restrictions on the  column in the 
+  table, particularly on length, also apply to port names.  Refer to the
+  documentation for  names for details.
 
 
 
@@ -1839,10 +1847,37 @@
 
 
   
-Interface name.  Should be alphanumeric and no more than about 8 bytes
-long.  May be the same as the port name, for non-bonded ports.  Must
-otherwise be unique among the names of ports, interfaces, and bridges
-on a host.
+
+  Interface name.  Should be alphanumeric.  For non-bonded port, this
+  should be the same as the port name.  It must otherwise be unique
+  among the names of ports, interfaces, and bridges on a host.
+
+
+
+  The maximum length of an interface name depends on the underlying
+  datapath:
+
+
+
+  
+The names of interfaces implemented as Linux and BSD network
+devices, including interfaces with type internal,
+tap, or system, are limited to 15 bytes.
+Windows limits these names to 255 bytes.
+  
+
+  
+The names of tunnels and patch ports are not used in the underlying
+datapath, so operating system restrictions do not apply.  Thus,
+they may have arbitrary length.
+  
+
+
+
+  Regardless of other restrictions, OpenFlow only supports 15-byte
+  names, which means that ovs-ofctl and OpenFlow
+  controllers will show names truncated to 15 bytes.
+
   
 
   
-- 
2.1.3

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

[ovs-dev] [PATCH branch-2.4] tests: Fix lookup segmentation test.

2016-05-26 Thread Joe Stringer

This test has been failing since IGMP megaflow matching was fixed.
Update the test to fix the build.

Fixes: aeb14ab7f6cd ("ofproto-dpif-xlate: Fix IGMP megaflow matching.")
Signed-off-by: Joe Stringer 
---
 tests/classifier.at | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/classifier.at b/tests/classifier.at
index c13fd775d763..9a4f28979422 100644
--- a/tests/classifier.at
+++ b/tests/classifier.at
@@ -49,7 +49,7 @@ Datapath actions: 1
 ])
 AT_CHECK([ovs-appctl ofproto/trace br0 
'in_port=1,dl_src=50:54:00:00:00:05,dl_dst=50:54:00:00:00:07,dl_type=0x0800,nw_src=192.168.0.1,nw_dst=11.1.2.15,nw_proto=6,nw_tos=0,nw_ttl=128,tp_src=8,tp_dst=80'],
 [0], [stdout])
 AT_CHECK([tail -2 stdout], [0],
-  [Megaflow: recirc_id=0,ip,in_port=1,nw_dst=1.0.0.0/1.0.0.0,nw_frag=no
+  [Megaflow: recirc_id=0,tcp,in_port=1,nw_dst=1.0.0.0/1.0.0.0,nw_frag=no
 Datapath actions: drop
 ])
 AT_CHECK([ovs-appctl ofproto/trace br0 
'in_port=1,dl_src=50:54:00:00:00:05,dl_dst=50:54:00:00:00:07,dl_type=0x0800,nw_src=192.168.0.1,nw_dst=10.1.2.15,nw_proto=6,nw_tos=0,nw_ttl=128,tp_src=8,tp_dst=80'],
 [0], [stdout])
-- 
2.8.2

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

[ovs-dev] Emailing: photo 05-26-2016, 71 00 27

2016-05-26 Thread dev


Your message is ready to be sent with the following file or link
attachments:

photo 05-26-2016, 71 00 27


Note: To protect against computer viruses, e-mail programs may prevent
sending or receiving certain types of file attachments.  Check your e-mail
security settings to determine how attachments are handled.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] tests: bfd.at: Fix bridge name in comment

2016-05-26 Thread Ben Pfaff

On Thu, May 26, 2016 at 04:23:02PM +0100, Markos Chandras wrote:
> The bridge sitting between 'br-bfd0' and 'br-bfd1' is called 'br-sw'
> instead of 'br2' and the patch ports are 'p0-sw' and 'p1-sw' instead
> of 'p0-2' and 'p1-2' respectively so fix the comment.
> 
> Signed-off-by: Markos Chandras 

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

Re: [ovs-dev] [PATCH] util: Drop 'date' and 'time' arguments from ovs_set_program_name

2016-05-26 Thread Ben Pfaff

On Thu, May 26, 2016 at 10:02:54AM +0100, Markos Chandras wrote:
> The 'date' and 'time' arguments are normally being set by
> 'ovs_set_program_name' using __DATE__ and __TIME__. However, this
> breaks reproducible builds since even without any changes in the
> toolchain, build system etc, the end binary will still differ in
> that regard. This is also visible when building with -Wdate-time:
> 
> utilities/ovs-dpctl.c:61:29: warning: macro "__DATE__" might prevent
> reproducible builds [-Wdate-time]
>  set_program_name(argv[0]);
>  ^
> 
> and it's also something that triggers the following warning in the
> openSUSE OBS builds:
> 
> [...]
> openvswitch.x86_64: W: file-contains-date-and-time /usr/bin/ovs-ofctl
> openvswitch.x86_64: W: file-contains-date-and-time /usr/bin/ovs-appctl
> Your file uses  __DATE and __TIME__ this causes the package to rebuild
> when not needed
> [...]
> 
> This patch drops these two arguments from ovs_set_program_name__ and
> renames the function to ovs_set_program_name dropping the previous
> preprocessor macro in the process.
> 
> This finally removes the remaining references to __DATE__ and __TIME__
> from the sources which is something that has already been done in
> commit 26bfaeaa9687 ("Stop using __DATE__ and __TIME__ in startup
> string.") for the kernel datapath.
> 
> Cc: Jan Engelhardt 
> Signed-off-by: Markos Chandras 

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

[ovs-dev] [PATCH v3] ovn-northd: logical router icmp response should not care about inport

2016-05-26 Thread Flavio Fernandes

When responding to icmp echo requests (aka ping) packets, the logical
router should not restrict responses based on the inport.

Example diagram:

vm: IP1.1 (subnet1)
logical_router: IP1.2 (subnet1) and IP2.2 (subnet2)

   vm ---[subnet1]--- logical_router ---[subnet2]
   

vm should be able to ping , even though it is an address
of a subnet that can only be reached through L3 routing.

Reference to the mailing list thread:
http://openvswitch.org/pipermail/discuss/2016-May/021172.html

---
Changes v1->v2:
  - Add unit test.

Changes v2->v3:
  - Code review feedback from Russell Bryant
  - Fix comment section on how vm can ping ip2.2

To be discussed:

One caveat here is that ttl should be decremented before vm
reaches , assuming the ping packet is coming from
a remote subnet.

In short, we ideally would have the match augmented to look
like this.

  "(inport == %s || ip.ttl > 1) && (ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") 
&& ...

Afer talking to Russel [1] it seems that we have either a bug or
a known limitation on how a match on ip.ttl can be used with the
greater than operator. I tried a couple of tweaks [2] against a
test ping with ttl 10 and concluded that both
negation and greater than are not working as expected. Assuming
ip.ttl should be supported in the match, there are 3 issues that
should be followed upon, which may be outside the scope of this
patch:
  1) fix/support negation and greater than operator for ip.ttl
  2) update doc on supported matches (ovn-sb);
  3) expand unit tests to verify ip.ttl in match

[1]: https://gist.github.com/725798db0ec7c607c648e3e85d338aa7

[2]:
* Works when sending test ping from non-local subnet and a ttl of 10:

  "(inport == %s || ip.ttl == 10) && (ip4.dst == "IP_FMT" || ip4.dst == 
"IP_FMT") && " ...
  "(inport == %s || ip.ttl == {2, 3, 4, 5, 6, 7, 8, 9, 10}) && (ip4.dst == 
"IP_FMT" || ip4.dst == "IP_FMT") && " ...

* Does NOT work when sending ping from non-local subnet and a ttl of 10:

  "(inport == %s || ip.ttl > 1) && (ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") 
&& " ...
  "(inport == %s || ip.ttl != {2, 3, 4, 5, 6, 7, 8, 9}) && (ip4.dst == "IP_FMT" 
|| ip4.dst == "IP_FMT") && " ...
  "!(inport != %s && ip.ttl == {0,1}) && (ip4.dst == "IP_FMT" || ip4.dst == 
"IP_FMT") && " ...
  "(inport == %s || !(ip.ttl == {0, 1})) && (ip4.dst == "IP_FMT" || ip4.dst == 
"IP_FMT") && " ...

Signed-off-by: Flavio Fernandes 
---
 ovn/northd/ovn-northd.c |   6 +-
 tests/ovn.at| 173 
 2 files changed, 177 insertions(+), 2 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 44e9430..f295052 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -1892,9 +1892,11 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 free(match);
 
 /* ICMP echo reply.  These flows reply to ICMP echo requests
- * received for the router's IP address. */
+ * received for the router's IP address. Since packets only
+ * get here as part of the logical router datapath, the inport
+ * (i.e. the incoming locally attached net) does not matter. */
 match = xasprintf(
-"inport == %s && (ip4.dst == "IP_FMT" || ip4.dst == "IP_FMT") && "
+"(inport == %s || ip.ttl > 1) && (ip4.dst == "IP_FMT" || ip4.dst 
== "IP_FMT") && "
 "icmp4.type == 8 && icmp4.code == 0",
 op->json_key, IP_ARGS(op->ip), IP_ARGS(op->bcast));
 char *actions = xasprintf(
diff --git a/tests/ovn.at b/tests/ovn.at
index e6ac1d7..8cd3677 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -2611,3 +2611,176 @@ OVS_APP_EXIT_AND_WAIT([ovs-vswitchd])
 OVS_APP_EXIT_AND_WAIT([ovsdb-server])
 
 AT_CLEANUP
+
+AT_SETUP([ovn -- icmp_reply: 1 HVs, 2 LSs, 1 lport/LS, 1 LR])
+AT_KEYWORDS([router-icmp-reply])
+AT_SKIP_IF([test $HAVE_PYTHON = no])
+ovn_start
+
+# Logical network:
+# One LR - R1 has switch ls1 (191.168.1.0/24) connected to it,
+# and has switch ls2 (172.16.1.0/24) connected to it.
+
+ovn-nbctl create Logical_Router name=R1
+
+ovn-nbctl lswitch-add ls1
+ovn-nbctl lswitch-add ls2
+
+# Connect ls1 to R1
+ovn-nbctl -- --id=@lrp create Logical_Router_port name=ls1 \
+network=192.168.1.1/24 mac=\"00:00:00:01:02:f1\" -- add Logical_Router R1 \
+ports @lrp -- lport-add ls1 rp-ls1
+
+ovn-nbctl set Logical_port rp-ls1 type=router options:router-port=ls1 \
+addresses=\"00:00:00:01:02:f1\"
+
+# Connect ls2 to R1
+ovn-nbctl -- --id=@lrp create Logical_Router_port name=ls2 \
+network=172.16.1.1/24 mac=\"00:00:00:01:02:f2\" -- add Logical_Router R1 \
+ports @lrp -- lport-add ls2 rp-ls2
+
+ovn-nbctl set Logical_port rp-ls2 type=router options:router-port=ls2 \
+addresses=\"00:00:00:01:02:f2\"
+
+# Create logical port ls1-lp1 in ls1
+ovn-nbctl lport-add ls1 ls1-lp1 \
+-- lport-set-addresses ls1-lp1 "00:00:00:01:02:03 192.168.1.2"
+
+# Create logical port ls2-lp1 in ls2

Re: [ovs-dev] Question on L3 Logical Router in vtep-emulator

2016-05-26 Thread Kyle Mestery

On Thu, May 26, 2016 at 10:46 AM, Guru Shetty  wrote:
>
>>
>>
>> OK, I'm going to play with this a bit. I was mostly interested in
>> feedback from others. We're interested in this approach and so if we
>> take the patch up does it stand a chance of merging?
>
>
> If I remember correctly, the main problem was around ARP handling when the
> destination's mac address is not known. Who would do the job that
> ovn-controller currently does for OVN? If a clean solution is proposed, then
> I can't think of any reasons why it can't be merged.
>
Your last comments said you also didn't appreciate the overall
approach, which is what I was referring to.

Either way, yes, the ARP handling needs to be solved, and VTEP schema
likely needs some work around NAT as you say. I'm going to revive this
patch and see what can be done here.

Thanks!
Kyle

>>
>>
>> >>
>> >>
>> >> >>
>> >> >>
>> >> >> Thanks!
>> >> >> Kyle
>> >> >>
>> >> >> [1] https://patchwork.ozlabs.org/patch/553435/
>> >> >> ___
>> >> >> dev mailing list
>> >> >> dev@openvswitch.org
>> >> >> http://openvswitch.org/mailman/listinfo/dev
>> >> >
>> >> >
>> >
>> >
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Summons On The Case #999E63B2

2016-05-26 Thread Eunice Leese

Good day, You are being summonsed to the court on the case #999E63B2.The 
penalty in the amount of $4,941,88 will be assigned in case you don't show 
up.Information on the case is listed in the document enclosed.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Question on L3 Logical Router in vtep-emulator

2016-05-26 Thread Guru Shetty

>
>
> OK, I'm going to play with this a bit. I was mostly interested in
> feedback from others. We're interested in this approach and so if we
> take the patch up does it stand a chance of merging?
>

If I remember correctly, the main problem was around ARP handling when the
destination's mac address is not known. Who would do the job that
ovn-controller currently does for OVN? If a clean solution is proposed,
then I can't think of any reasons why it can't be merged.


>
> >>
> >>
> >> >>
> >> >>
> >> >> Thanks!
> >> >> Kyle
> >> >>
> >> >> [1] https://patchwork.ozlabs.org/patch/553435/
> >> >> ___
> >> >> 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] Question on L3 Logical Router in vtep-emulator

2016-05-26 Thread Kyle Mestery

On Thu, May 26, 2016 at 10:20 AM, Guru Shetty  wrote:
>
>
> On 26 MaVTEP schema based L3 gateway in particular?
>>
>> >
>> Thanks Guru. I was looking at the VTEP schema based L3 GW as well, and
>> wondering if this patch had pretty much been abandoned. I can see some
>> use for using VTEP as an L3 edge device.
>
>
> The patch has been abandoned for the time being. I don't know of anyone
> actively working on it right now.
>
OK, I'm going to play with this a bit. I was mostly interested in
feedback from others. We're interested in this approach and so if we
take the patch up does it stand a chance of merging?

>>
>>
>> >>
>> >>
>> >> Thanks!
>> >> Kyle
>> >>
>> >> [1] https://patchwork.ozlabs.org/patch/553435/
>> >> ___
>> >> dev mailing list
>> >> dev@openvswitch.org
>> >> http://openvswitch.org/mailman/listinfo/dev
>> >
>> >
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] tests: bfd.at: Fix bridge name in comment

2016-05-26 Thread Markos Chandras

The bridge sitting between 'br-bfd0' and 'br-bfd1' is called 'br-sw'
instead of 'br2' and the patch ports are 'p0-sw' and 'p1-sw' instead
of 'p0-2' and 'p1-2' respectively so fix the comment.

Signed-off-by: Markos Chandras 
---
 tests/bfd.at | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/bfd.at b/tests/bfd.at
index 925af77..8bbf00b 100644
--- a/tests/bfd.at
+++ b/tests/bfd.at
@@ -85,8 +85,8 @@ AT_CLEANUP
 
 
 AT_SETUP([bfd - Verify tunnel down detection])
-#Create 3 bridges - br-bfd0, br-bfd1 and br-sw which is midway between the 
two. br2 is
-#connected to br-bfd0 and br-bfd1 through patch ports p0-2 and p1-2. Enable 
BFD on
+#Create 3 bridges - br-bfd0, br-bfd1 and br-sw which is midway between the 
two. br-sw is
+#connected to br-bfd0 and br-bfd1 through patch ports p0-sw and p1-sw. Enable 
BFD on
 #interfaces in br-bfd0 and br-bfd1. When br-sw is dropping all packets, BFD 
should detect
 # that the tunnel is down, and come back up when br-sw is working fine.
 
-- 
2.8.2

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

Re: [ovs-dev] Question on L3 Logical Router in vtep-emulator

2016-05-26 Thread Guru Shetty

On 26 MaVTEP schema based L3 gateway in particular?
>
> >
> Thanks Guru. I was looking at the VTEP schema based L3 GW as well, and
> wondering if this patch had pretty much been abandoned. I can see some
> use for using VTEP as an L3 edge device.
>

The patch has been abandoned for the time being. I don't know of anyone
actively working on it right now.


>
> >>
> >>
> >> Thanks!
> >> Kyle
> >>
> >> [1] https://patchwork.ozlabs.org/patch/553435/
> >> ___
> >> dev mailing list
> >> dev@openvswitch.org
> >> http://openvswitch.org/mailman/listinfo/dev
> >
> >
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Your Package #87772

2016-05-26 Thread Guiimar Castillo

Hello!Your package will be delivered in the shortest time possible. The 
tracking number is #613952139. In addition, you can find all the other 
information regarding your order in the file enclosed. Thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Question on L3 Logical Router in vtep-emulator

2016-05-26 Thread Kyle Mestery

On Thu, May 26, 2016 at 9:44 AM, Guru Shetty  wrote:
>
> On 26 May 2016 at 07:13, Kyle Mestery  wrote:
>>
>> Greetings!
>>
>> I was looking for some L3 related items and came across the following
>> patch on patchworks [1]. This was some work done to add L3 routing to
>> the vtep emulator. Guru had commented on this indicating the
>> usefulness for using the vtep-emulator as a L3 edge device, but he had
>> a bunch of comments around the approach taken by Shuangmin. I never
>> saw a reply to Guru on list. What is the status of the thinking here?
>> I also see value in this as an L3 edge device.
>
>
> We do have a more sophisticated L3 gateway related patches out for review
> for OVN (This does not integrate with VTEP schema). Was your interest with
> L3 gateway in general or VTEP schema based L3 gateway in particular?
>
Thanks Guru. I was looking at the VTEP schema based L3 GW as well, and
wondering if this patch had pretty much been abandoned. I can see some
use for using VTEP as an L3 edge device.

>>
>>
>> Thanks!
>> Kyle
>>
>> [1] https://patchwork.ozlabs.org/patch/553435/
>> ___
>> 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] Question on L3 Logical Router in vtep-emulator

2016-05-26 Thread Guru Shetty

On 26 May 2016 at 07:13, Kyle Mestery  wrote:

> Greetings!
>
> I was looking for some L3 related items and came across the following
> patch on patchworks [1]. This was some work done to add L3 routing to
> the vtep emulator. Guru had commented on this indicating the
> usefulness for using the vtep-emulator as a L3 edge device, but he had
> a bunch of comments around the approach taken by Shuangmin. I never
> saw a reply to Guru on list. What is the status of the thinking here?
> I also see value in this as an L3 edge device.
>

We do have a more sophisticated L3 gateway related patches out for review
for OVN (This does not integrate with VTEP schema). Was your interest with
L3 gateway in general or VTEP schema based L3 gateway in particular?


>
> Thanks!
> Kyle
>
> [1] https://patchwork.ozlabs.org/patch/553435/
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Question on L3 Logical Router in vtep-emulator

2016-05-26 Thread Kyle Mestery

Greetings!

I was looking for some L3 related items and came across the following
patch on patchworks [1]. This was some work done to add L3 routing to
the vtep emulator. Guru had commented on this indicating the
usefulness for using the vtep-emulator as a L3 edge device, but he had
a bunch of comments around the approach taken by Shuangmin. I never
saw a reply to Guru on list. What is the status of the thinking here?
I also see value in this as an L3 edge device.

Thanks!
Kyle

[1] https://patchwork.ozlabs.org/patch/553435/
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC] ovs-tcpdump: Add a tcpdump wrapper utility

2016-05-26 Thread Aaron Conole

Flavio Leitner  writes:

> On Wed, May 25, 2016 at 11:08:37AM -0400, Aaron Conole wrote:
>> Flavio Leitner  writes:
>> > On Tue, May 24, 2016 at 04:35:29PM -0400, Aaron Conole wrote:
> [...] 
>> >> +
>> >> +ovsdb = OVSDB(db_sock)
>> >> +if mirror_interface is None:
>> >
>> > mirror_interface is referenced but it hasn't been initialized.
>> 
>> Python :-)  Technically, it's allowed, and flake8 or pyflakes doesn't
>> complain (because it is perfectly valid python).  However, I can
>> rewrite it something like
>> 
>> mirror_interface = None
>> ...
>> mirror_interface = mirror_interface or "mi_%s" % interface
>> 
>> if you think that feels more natural. Doesn't matter to me.
>
> I tried something simple:
>
>>>> def func():
>... if NotDeclared:
>... pass
>... 
>>>> func()
>Traceback (most recent call last):
>  File "", line 1, in 
>  File "", line 2, in func
>NameError: global name 'NotDeclared' is not defined
>
> and it complains. :-)
> [Python 2.7.11]

Hrrm... no idea why my testing didn't cause it to die then. I'm an idiot
and I'll fix it.

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

Re: [ovs-dev] [PATCH v5 0/2] doc: Refactor DPDK install guide

2016-05-26 Thread Bodireddy, Bhanuprakash

Adding the reviewers of the INSTALL guide here, mistakenly had 
'--suppress-cc=all'. 

Bhanuprakash.

>-Original Message-
>From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of
>Bhanuprakash Bodireddy
>Sent: Thursday, May 26, 2016 1:47 PM
>To: dev@openvswitch.org
>Cc: Traynor, Kevin 
>Subject: [ovs-dev] [PATCH v5 0/2] doc: Refactor DPDK install guide
>
>This patchset refactors the present INSTALL.DPDK.md guide.
>
>The INSTALL guide is split in to two documents named INSTALL.DPDK and
>INSTALL.DPDK-ADVANCED. The former document is simplified with emphasis
>on installation, basic testcases and targets novice users. Sections on system
>configuration, performance tuning, vhost walkthrough and IVSHMEM are
>moved to DPDK-ADVANCED guide.
>
>Reviewers can review the rendered form here
>https://github.com/bbodired/ovs/blob/master/INSTALL.DPDK.md
>https://github.com/bbodired/ovs/blob/master/INSTALL.DPDK-
>ADVANCED.md
>
>v4->v5:
>* Rebased
>* Add Ingress Policing Example in Rate Limiting section, Advanced Guide
>* Minor fixes in Install DPDK, INSTALL OVS sections of INSTALL.DPDK.md
>
>V3->v4:
>* Refactor hugepage section in Beginner and Advanced guides
>* Added Guest libvirt configuration for vhostuser ports
>* General formatting changes, enable hyperlinks and wording changes
>
>v2->v3:
>* Rebased
>
>v1->v2:
>* Rebased
>* Update DPDK version to 16.04
>* Add vsperf section in ADVANCED Guide
>
>Bhanuprakash Bodireddy (2):
>  doc: Refactor DPDK install documentation
>  doc: Refactor DPDK install guide, add ADVANCED doc
>
> INSTALL.DPDK-ADVANCED.md |  863 ++
> INSTALL.DPDK.md  | 1299 +++---
> 2 files changed, 1292 insertions(+), 870 deletions(-)  create mode 100644
>INSTALL.DPDK-ADVANCED.md
>
>--
>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

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

2016-05-26 Thread Bhanuprakash Bodireddy

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 
---
 INSTALL.DPDK-ADVANCED.md | 863 +++
 1 file changed, 863 insertions(+)
 create mode 100644 INSTALL.DPDK-ADVANCED.md

diff --git a/INSTALL.DPDK-ADVANCED.md b/INSTALL.DPDK-ADVANCED.md
new file mode 100644
index 000..44939a6
--- /dev/null
+++ b/INSTALL.DPDK-ADVANCED.md
@@ -0,0 +1,863 @@
+OVS DPDK ADVANCED INSTALL GUIDE
+=
+
+## Contents
+
+1. [Overview](#overview)
+2. [Building Shared Library](#build)
+3. [System configuration](#sysconf)
+4. [Performance Tuning](#perftune)
+5. [OVS Testcases](#ovstc)
+6. [Vhost Walkthrough](#vhost)
+7. [QOS](#qos)
+8. [Rate Limiting](#rl)
+9. [Static Code Analysis](#staticanalyzer)
+10. [Vsperf](#vsperf)
+
+##  1. Overview
+
+The Advanced Install Guide explains how to improve OVS performance using
+DPDK datapath. This guide also provides information on tuning, system 
configuration,
+troubleshooting, static code analysis and testcases.
+
+##  2. Building Shared Library
+
+DPDK can be built as static or shared library and shall be linked by 
applications
+using DPDK datapath. The section lists steps to build shared library and 
dynamically
+link DPDK against OVS.
+
+Note: Minor performance loss is seen with OVS when using shared DPDK library as
+compared to static library.
+
+Check section [INSTALL DPDK], [INSTALL OVS] of INSTALL.DPDK on download 
instructions
+for DPDK and OVS.
+
+  * Configure the DPDK library
+
+  Set `CONFIG_RTE_BUILD_SHARED_LIB=y` in `config/common_base`
+  to generate shared DPDK library
+
+
+  * Build and install DPDK
+
+For Default install (without IVSHMEM), set `export 
DPDK_TARGET=x86_64-native-linuxapp-gcc`
+For IVSHMEM case, set `export DPDK_TARGET=x86_64-ivshmem-linuxapp-gcc`
+
+```
+export DPDK_DIR=/usr/src/dpdk-16.04
+export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
+make install T=$DPDK_TARGET DESTDIR=install
+```
+
+  * Build, Install and Setup OVS.
+
+  Export the DPDK shared library location and setup OVS as listed in
+  section 3.3 of INSTALL.DPDK.
+
+  `export LD_LIBRARY_PATH=$DPDK_DIR/x86_64-native-linuxapp-gcc/lib`
+
+##  3. System Configuration
+
+To achieve optimal OVS performance, the system can be configured and that 
includes
+BIOS tweaks, Grub cmdline additions, better understanding of NUMA nodes and
+apt selection of PCIe slots for NIC placement.
+
+### 3.1 Recommended BIOS settings
+
+  ```
+  | Settings  | values| comments
+  |---|---|---
+  | C3 power state| Disabled  | -
+  | C6 power state| Disabled  | -
+  | MLC Streamer  | Enabled   | -
+  | MLC Spacial prefetcher| Enabled   | -
+  | DCU Data prefetcher   | Enabled   | -
+  | DCA   | Enabled   | -
+  | CPU power and performance | Performance -
+  | Memory RAS and perf   |   | -
+config-> NUMA optimized   | Enabled   | -
+  ```
+
+### 3.2 PCIe Slot Selection
+
+The fastpath performance also depends on factors like the NIC placement,
+Channel speeds between PCIe slot and CPU, proximity of PCIe slot to the CPU
+cores running DPDK application. Listed below are the steps to identify
+right PCIe slot.
+
+- Retrieve host details using cmd `dmidecode -t baseboard | grep "Product 
Name"`
+- Download the technical specification for Product listed eg: S2600WT2.
+- Check the Product Architecture Overview on the Riser slot placement,
+  CPU sharing info and also PCIe channel speeds.
+
+  example: On S2600WT, CPU1 and CPU2 share Riser Slot 1 with Channel speed 
between
+  CPU1 and Riser Slot1 at 32GB/s, CPU2 and Riser Slot1 at 16GB/s. Running DPDK 
app
+  on CPU1 cores and NIC inserted in to Riser card Slots will optimize OVS 
performance
+  in this case.
+
+- Check the Riser Card #1 - Root Port mapping information, on the available 
slots
+  and individual bus speeds. In S2600WT slot 1, slot 2 has high bus speeds and 
are
+  potential slots for NIC placement.
+
+### 3.3 Advanced Hugepage setup
+
+  Allocate and mount 1G Huge pages:
+
+  - For persistent allocation of huge pages, add the following options to the 
kernel bootline
+
+  Add `default_hugepagesz=1GB hugepagesz=1G hugepages=N`
+
+  For platforms supporting multiple huge page sizes, Add options
+
+  `default_hugepagesz= hugepagesz= hugepages=N`
+  where 'N' = Number of huge pages requested, 'size' = huge page size,
+  optional suffix [kKmMgG]
+
+  - For run-time allocation of huge pages
+
+  `echo N > 
/sys/devices/system/node/nodeX/hugepages/hugepages-1048576kB/nr_hugepages`
+  where 'N' = Number of huge pages requested, 'X' = NUMA Node
+
+  Note: For run-time allocation of 1G huge pages, Contiguous

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

2016-05-26 Thread Bhanuprakash Bodireddy

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
+
 
-Open vSwitch can use Intel(R) DPDK lib to operate entirely in
-userspace. This file explains how to install and use Open vSwitch in
-such a mode.
+## Contents
 
-The DPDK support of Open vSwitch is considered experimental.
-It has not been thoroughly tested.
+1. [Overview](#overview)
+2. [Building and Installation](#build)
+3. [Setup OVS DPDK datapath](#ovssetup)
+4. [DPDK in the VM](#builddpdk)
+5. [OVS Testcases](#ovstc)
+6. [Limitations ](#ovslimits)
 
-This version of Open vSwitch should be built manually with `configure`
-and `make`.
+##  1. Overview
 
-OVS needs a system with 1GB hugepages support.
+Open vSwitch can use DPDK lib to operate entirely in userspace.
+This file provides information on installation and use of Open vSwitch
+using DPDK datapath.  This version of Open vSwitch should be built manually
+with `configure` and `make`.
 
-Building and Installing:
-
+The DPDK support of Open vSwitch is considered 'experimental'.
 
-Required: DPDK 16.04
-Optional (if building with vhost-cuse): `fuse`, `fuse-devel` (`libfuse-dev`
-on Debian/Ubuntu)
+### Prerequisites
 
-1. Configure build & install DPDK:
-  1. Set `$DPDK_DIR`
+* Required: DPDK 16.04
+* Hardware: [DPDK Supported NICs] when physical ports in use
 
- ```
- export DPDK_DIR=/usr/src/dpdk-16.04
- cd $DPDK_DIR
- ```
-
-  2. Then run `make install` to build and install the library.
- For default install without IVSHMEM:
-
- `make install T=x86_64-native-linuxapp-gcc DESTDIR=install`
-
- To include IVSHMEM (shared memory):
-
- `make install T=x86_64-ivshmem-linuxapp-gcc DESTDIR=install`
-
- For further details refer to http://dpdk.org/
-
-2. Configure & build the Linux kernel:
-
-   Refer to intel-dpdk-getting-started-guide.pdf for understanding
-   DPDK kernel requirement.
-
-3. Configure & build OVS:
-
-   * Non IVSHMEM:
-
- `export DPDK_BUILD=$DPDK_DIR/x86_64-native-linuxapp-gcc/`
-
-   * IVSHMEM:
-
- `export DPDK_BUILD=$DPDK_DIR/x86_64-ivshmem-linuxapp-gcc/`
-
-   ```
-   cd $(OVS_DIR)/
-   ./boot.sh
-   ./configure --with-dpdk=$DPDK_BUILD [CFLAGS="-g -O2 -Wno-cast-align"]
-   make
-   ```
-
-   Note: 'clang' users may specify the '-Wno-cast-align' flag to suppress DPDK 
cast-align warnings.
-
-To have better performance one can enable aggressive compiler optimizations and
-use the special instructions(popcnt, crc32) that may not be available on all
-machines. Instead of typing `make`, type:
-
-`make CFLAGS='-O3 -march=native'`
-
-Refer to [INSTALL.userspace.md] for general requirements of building userspace 
OVS.
-
-Using the DPDK with ovs-vswitchd:
--
-
-1. Setup system boot
-   Add the following options to the kernel bootline:
-   
-   `default_hugepagesz=1GB hugepagesz=1G hugepages=1`
-
-2. Setup DPDK devices:
-
-   DPDK devices can be setup using either the VFIO (for DPDK 1.7+) or UIO
-   modules. UIO requires inserting an out of tree driver igb_uio.ko that is
-   available in DPDK. Setup for both methods are described below.
-
-   * UIO:
- 1. insert uio.ko: `modprobe uio`
- 2. insert igb_uio.ko: `insmod $DPDK_BUILD/kmod/igb_uio.ko`
- 3. Bind network device to igb_uio:
- `$DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio eth1`
-
-   * VFIO:
-
- VFIO needs to be supported in the kernel and the BIOS. More information
- can be found in the [DPDK Linux GSG].
-
- 1. Insert vfio-pci.ko: `modprobe vfio-pci`
- 2. Set correct permissions on vfio device: `sudo /usr/bin/chmod a+x 
/dev/vfio`
-and: `sudo /usr/bin/chmod 0666 /dev/vfio/*`
- 3. Bind network device to vfio-pci:
-`$DPDK_DIR/tools/dpdk_nic_bind.py --bind=vfio-pci eth1`
-
-3. Mount the hugetable filesystem
-
-   `mount -t hugetlbfs -o pagesize=1G none /dev/hugepages`
-
-   Ref to http://www.dpdk.org/doc/quick-start for verifying DPDK setup.
-
-4. Follow the instructions in [INSTALL.md] to install only the
-   userspace daemons and utilities (via 'make install').
-   1. First time only db creation (or clearing):
-
-  ```
-  mkdir -p /usr/local/etc/openvswitch
-  mkdir -p /usr/local/var/run/openvswitch

[ovs-dev] [PATCH v5 0/2] doc: Refactor DPDK install guide

2016-05-26 Thread Bhanuprakash Bodireddy

This patchset refactors the present INSTALL.DPDK.md guide.

The INSTALL guide is split in to two documents named INSTALL.DPDK and
INSTALL.DPDK-ADVANCED. The former document is simplified with emphasis
on installation, basic testcases and targets novice users. Sections on
system configuration, performance tuning, vhost walkthrough and IVSHMEM
are moved to DPDK-ADVANCED guide.

Reviewers can review the rendered form here 
https://github.com/bbodired/ovs/blob/master/INSTALL.DPDK.md
https://github.com/bbodired/ovs/blob/master/INSTALL.DPDK-ADVANCED.md

v4->v5:
* Rebased
* Add Ingress Policing Example in Rate Limiting section, Advanced Guide
* Minor fixes in Install DPDK, INSTALL OVS sections of INSTALL.DPDK.md

V3->v4:
* Refactor hugepage section in Beginner and Advanced guides
* Added Guest libvirt configuration for vhostuser ports
* General formatting changes, enable hyperlinks and wording changes

v2->v3:
* Rebased

v1->v2:
* Rebased
* Update DPDK version to 16.04
* Add vsperf section in ADVANCED Guide

Bhanuprakash Bodireddy (2):
  doc: Refactor DPDK install documentation
  doc: Refactor DPDK install guide, add ADVANCED doc

 INSTALL.DPDK-ADVANCED.md |  863 ++
 INSTALL.DPDK.md  | 1299 +++---
 2 files changed, 1292 insertions(+), 870 deletions(-)
 create mode 100644 INSTALL.DPDK-ADVANCED.md

-- 
2.4.11

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

[ovs-dev] Credit Card Has Been Declined *9348

2016-05-26 Thread Brena Patterson

Your credit card has been declined, cancellation notice is enclosed down below.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] (no subject)

2016-05-26 Thread Grant Barlow

Dear dev,

Please find attached a document containing our responses to the other points 
which we
discussed on Monday 23th May.

Please let me know if you have any queries


Regards,

Mosaic Company (The)
Grant Barlow
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] (no subject)

2016-05-26 Thread Robin Cabrera

Dear dev,

Please find attached a document containing our responses to the other points 
which we
discussed on Monday 23th May.

Please let me know if you have any queries


Regards,

Ashford Hospitality Trust Inc
Robin Cabrera
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] (no subject)

2016-05-26 Thread Roxie Baldwin

Dear dev,

Please find attached a document containing our responses to the other points 
which we
discussed on Monday 23th May.

Please let me know if you have any queries


Regards,

NII Holdings, Inc.
Roxie Baldwin
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] datapath-windows: Add support for UDP and ICMP to Conntrack Module

2016-05-26 Thread Alin Serdean

I am unsure if we actual need another file but that maybe a personal preference.

Other comments inlined.

Alin.
> +
> +static const long long other_timeouts[] = {
> +[OTHERS_FIRST] = 60 * 1000,
> +[OTHERS_MULTIPLE] = 60 * 1000,
> +[OTHERS_BIDIR] = 30 * 1000,
> +};
[Alin Gabriel Serdean: ] Maybe define 1000 somewhere and add a comment on 
how many ms/s they will be.
> +
> +static __inline struct conn_other*
> +OvsCastConntrackEntryToOtherEntry(OVS_CT_ENTRY *conn) {
> +return CONTAINER_OF(conn, struct conn_other, up); }
[Alin Gabriel Serdean: ] Add an assert conn
> +
> +static __inline VOID
> +OvsConntrackUpdateExpiration(struct conn_other *conn, long long now) {
> +conn->up.expiration = now + other_timeouts[conn->state]; }
[Alin Gabriel Serdean: ] Add an assert to conn
> +
> +enum ct_update_res
> +OvsConntrackUpdateOtherEntry(OVS_CT_ENTRY *conn_,
> + BOOLEAN reply,
> + UINT64 now) {
> +struct conn_other *conn = OvsCastConntrackEntryToOtherEntry(conn_);
[Alin Gabriel Serdean: ] Add an assert to conn_
> +
> +OVS_CT_ENTRY *
> +OvsConntrackCreateOtherEntry(UINT64 now) {
> +struct conn_other *conn;
> +conn = OvsAllocateMemoryWithTag(sizeof(struct conn_other),
> +OVS_CT_POOL_TAG);
> +/* XXX Handle memory allocation error*/
[Alin Gabriel Serdean: ] Please handle the memory allocation or at least add an 
assert to it
> +conn->up = (OVS_CT_ENTRY) {0};
> +conn->state = OTHERS_FIRST;
> +OvsConntrackUpdateExpiration(conn, now);
> +return >up;
> +}
> \ No newline at end of file
[Alin Gabriel Serdean: ] Nit no new line
> diff --git a/datapath-windows/ovsext/Conntrack.c b/datapath-
> windows/ovsext/Conntrack.c
> index 544fd51..e193e9f 100644
> --- a/datapath-windows/ovsext/Conntrack.c
> +++ b/datapath-windows/ovsext/Conntrack.c
> @@ -146,9 +146,20 @@ OvsCtUpdateFlowKey(struct OvsFlowKey *key,
>  }
>  }
> 
> +static __inline VOID
> +OvsCtAddEntry(POVS_CT_ENTRY entry, OvsConntrackKeyLookupCtx *ctx) {
> +NdisMoveMemory(>key, >key, sizeof (OVS_CT_KEY));
> +NdisMoveMemory(>rev_key, >key, sizeof (OVS_CT_KEY));
[Alin Gabriel Serdean: ] Maybe use RtlCopyMemory
> +OvsCtKeyReverse(>rev_key);
> +InsertHeadList([ctx->hash &
> CT_HASH_TABLE_MASK],
> +   >link);
> +}
> +
>  static __inline POVS_CT_ENTRY
> -OvsCtEntryCreate(const TCPHdr *tcp,
> - PNET_BUFFER_LIST curNbl,
> +OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
> + UINT8 ipProto,
> + UINT32 l4Offset,
>   OvsConntrackKeyLookupCtx *ctx,
>   OvsFlowKey *key,
>   BOOLEAN commit,
> @@ -156,26 +167,71 @@ OvsCtEntryCreate(const TCPHdr *tcp,  {
>  POVS_CT_ENTRY entry = NULL;
>  UINT32 state = 0;
> -if (!OvsConntrackValidateTcpPacket(tcp)) {
> -state |= OVS_CS_F_INVALID;
> -OvsCtUpdateFlowKey(key, state, ctx->key.zone, 0, NULL);
> -return entry;
> -}
> +switch (ipProto)
> +{
> +case IPPROTO_TCP:
> +{
> +TCPHdr tcpStorage;
> +const TCPHdr *tcp;
> +tcp = OvsGetTcp(curNbl, l4Offset, );
> +if (!OvsConntrackValidateTcpPacket(tcp)) {
> +goto invalid;
> +}
> +
> +state |= OVS_CS_F_NEW;
> +if (commit) {
> +entry = OvsConntrackCreateTcpEntry(tcp, curNbl, currentTime);
> +OvsCtAddEntry(entry, ctx);
> +}
> +
> +OvsCtUpdateFlowKey(key, state, ctx->key.zone, 0, NULL);
> +return entry;
> +}
> +case IPPROTO_ICMP:
> +case IPPROTO_UDP:
> +state |= OVS_CS_F_NEW;
> +if (commit) {
> +entry = OvsConntrackCreateOtherEntry(currentTime);
> +OvsCtAddEntry(entry, ctx);
> +}
> 
> -state |= OVS_CS_F_NEW;
> -if (commit) {
> -entry = OvsConntrackCreateTcpEntry(tcp, curNbl, currentTime);
> -NdisMoveMemory(>key, >key, sizeof (OVS_CT_KEY));
> -NdisMoveMemory(>rev_key, >key, sizeof (OVS_CT_KEY));
> -OvsCtKeyReverse(>rev_key);
> -InsertHeadList([ctx->hash &
> CT_HASH_TABLE_MASK],
> -   >link);
> +OvsCtUpdateFlowKey(key, state, ctx->key.zone, 0, NULL);
> +return entry;
> +default:
> +goto invalid;
>  }
> 
> +invalid:
> +state |= OVS_CS_F_INVALID;
>  OvsCtUpdateFlowKey(key, state, ctx->key.zone, 0, NULL);
>  return entry;
>  }
> 
> +static enum CT_UPDATE_RES
> +OvsCtUpdateEntry(OVS_CT_ENTRY* entry,
> +PNET_BUFFER_LIST nbl,
> +UINT8 ipProto,
> +UINT32 l4Offset,
> +BOOLEAN reply,
> +UINT64 now)
> +{
> +switch (ipProto)
> +{
> +case IPPROTO_TCP:
> +{
> +

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

2016-05-26 Thread Post Office

The original message was received at Thu, 26 May 2016 15:27:47 +0530
from 173.24.165.20

- The following addresses had permanent fatal errors -


- Transcript of the session follows -
... while talking to openvswitch.org.:
>>> MAIL From:"Post Office" 
<<< 500 User blacklisted

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

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

2016-05-26 Thread Fischetti, Antonio

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: New userspace connection tracker.
>   conntrack: Periodically delete expired connections.
>   tests: Add very simple conntrack benchmark.
>   tests: Add test-conntrack pcap test.
>   dpif-netdev: Execute conntrack action.
>   dpif-netdev: Implement conntrack dump functions.
>   dpif-netdev: Implement conntrack flush interface.
>   flow: Fill udp_len in flow_compose_l4().
>   flow: Generate checksum in flow_compose().
>   tests: Add conntrack ofproto-dpif tests.
>   system-tests: Run conntrack tests with userspace.
>   system-tests: Add ping through conntrack test.
>   conntrack: Track ICMP type and code.
> 
>  COPYING  |1 +
>  FAQ.md   |2 +-
>  NEWS |2 +
>  debian/copyright.in  |4 +
>  include/openvswitch/types.h  |4 +
>  lib/automake.mk  |6 +
>  lib/conntrack-icmp.c |  105 
>  lib/conntrack-other.c|   86 +++
>  lib/conntrack-private.h  |  113 
>

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

2016-05-26 Thread Alin Serdean

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

[ovs-dev] Mail System Error - Returned Mail

2016-05-26 Thread MAILER-DAEMON

Dear user dev@openvswitch.org,

We have received reports that your e-mail account has been used to send a huge 
amount of spam messages during the last week.
Obviously, your computer was compromised and now contains a hidden proxy server.

We recommend that you follow our instruction in order to keep your computer 
safe.

Best regards,
The openvswitch.org team.

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

[ovs-dev] [PATCH] util: Drop 'date' and 'time' arguments from ovs_set_program_name

2016-05-26 Thread Markos Chandras

The 'date' and 'time' arguments are normally being set by
'ovs_set_program_name' using __DATE__ and __TIME__. However, this
breaks reproducible builds since even without any changes in the
toolchain, build system etc, the end binary will still differ in
that regard. This is also visible when building with -Wdate-time:

utilities/ovs-dpctl.c:61:29: warning: macro "__DATE__" might prevent
reproducible builds [-Wdate-time]
 set_program_name(argv[0]);
 ^

and it's also something that triggers the following warning in the
openSUSE OBS builds:

[...]
openvswitch.x86_64: W: file-contains-date-and-time /usr/bin/ovs-ofctl
openvswitch.x86_64: W: file-contains-date-and-time /usr/bin/ovs-appctl
Your file uses  __DATE and __TIME__ this causes the package to rebuild
when not needed
[...]

This patch drops these two arguments from ovs_set_program_name__ and
renames the function to ovs_set_program_name dropping the previous
preprocessor macro in the process.

This finally removes the remaining references to __DATE__ and __TIME__
from the sources which is something that has already been done in
commit 26bfaeaa9687 ("Stop using __DATE__ and __TIME__ in startup
string.") for the kernel datapath.

Cc: Jan Engelhardt 
Signed-off-by: Markos Chandras 
---
 include/openvswitch/util.h |  6 +-
 lib/util.c | 17 +
 2 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/include/openvswitch/util.h b/include/openvswitch/util.h
index 2230b2a..363fa39 100644
--- a/include/openvswitch/util.h
+++ b/include/openvswitch/util.h
@@ -25,11 +25,7 @@
 extern "C" {
 #endif
 
-void ovs_set_program_name__(const char *name, const char *version,
-const char *date, const char *time);
-
-#define ovs_set_program_name(name, version) \
-ovs_set_program_name__(name, version, __DATE__, __TIME__)
+void ovs_set_program_name(const char *name, const char *version);
 
 const char *ovs_get_program_name(void);
 const char *ovs_get_program_version(void);
diff --git a/lib/util.c b/lib/util.c
index 94311ac..6ca04ad 100644
--- a/lib/util.c
+++ b/lib/util.c
@@ -461,14 +461,9 @@ ovs_strerror(int error)
  * vSwitch.  Otherwise, it is assumed to be an external program linking against
  * the Open vSwitch libraries.
  *
- * The 'date' and 'time' arguments should likely be called with
- * "__DATE__" and "__TIME__" to use the time the binary was built.
- * Alternatively, the "ovs_set_program_name" macro may be called to do this
- * automatically.
  */
 void
-ovs_set_program_name__(const char *argv0, const char *version, const char 
*date,
-   const char *time)
+ovs_set_program_name(const char *argv0, const char *version)
 {
 char *basename;
 #ifdef _WIN32
@@ -496,14 +491,12 @@ ovs_set_program_name__(const char *argv0, const char 
*version, const char *date,
 
 free(program_version);
 if (!strcmp(version, VERSION)) {
-program_version = xasprintf("%s (Open vSwitch) "VERSION"\n"
-"Compiled %s %s\n",
-program_name, date, time);
+program_version = xasprintf("%s (Open vSwitch) "VERSION"\n",
+program_name);
 } else {
 program_version = xasprintf("%s %s\n"
-"Open vSwitch Library "VERSION"\n"
-"Compiled %s %s\n",
-program_name, version, date, time);
+"Open vSwitch Library "VERSION"\n",
+program_name, version);
 }
 }
 
-- 
2.8.2

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

Re: [ovs-dev] [PATCH v3 08/16] dpif-netdev: Execute conntrack action.

2016-05-26 Thread Fischetti, Antonio

It looks ok to me.
Thanks.

Acked-by: Antonio Fischetti 


> -Original Message-
> From: Daniele Di Proietto [mailto:diproiet...@vmware.com]
> Sent: Wednesday, May 25, 2016 9:57 PM
> To: Fischetti, Antonio 
> Cc: dev@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v3 08/16] dpif-netdev: Execute
> conntrack action.
> 
> 
> 
> 
> 
> 
> On 24/05/2016 08:52, "Fischetti, Antonio"
>  wrote:
> 
> >Hi Daniele, one question below.
> >
> >Thanks,
> >Antonio
> >
> >
> >> -Original Message-
> >> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of
> Daniele
> >> Di Proietto
> >> Sent: Tuesday, May 17, 2016 1:57 AM
> >> To: dev@openvswitch.org
> >> Subject: [ovs-dev] [PATCH v3 08/16] dpif-netdev: Execute conntrack
> >> action.
> >>
> >> This commit implements the OVS_ACTION_ATTR_CT action in dpif-
> netdev.
> >>
> >> To allow ofproto-dpif to detect the conntrack feature, flow_put
> will
> >> not
> >> discard anymore flows with ct_* fields set. We still shouldn't
> allow
> >> flows with NAT bits set, since there is no support for NAT.
> >>
> >> Signed-off-by: Daniele Di Proietto 
> >> Acked-by: Flavio Leitner 
> >> ---
> >>  FAQ.md|  2 +-
> >>  NEWS  |  2 ++
> >>  lib/dpif-netdev.c | 63
> >> ---
> >>  tests/dpif-netdev.at  | 14 ++--
> >>  tests/ofproto-dpif.at | 20 
> >>  5 files changed, 75 insertions(+), 26 deletions(-)
> >>
> >> diff --git a/FAQ.md b/FAQ.md
> >> index 5e95ccc..c111c32 100644
> >> --- a/FAQ.md
> >> +++ b/FAQ.md
> >> @@ -193,7 +193,7 @@ A: Open vSwitch supports different datapaths
> on
> >> different platforms.  Each
> >>  Feature   | Linux upstream | Linux OVS tree |
> Userspace
> >> | Hyper-V |
> >>  --|:--:|:--:|:---
> --
> >> :|:---:|
> >>  NAT   |  4.6   |   NO   |NO
> >> |   NO|
> >> -Connection tracking   |  4.3   |   YES  |NO
> >> | PARTIAL |
> >> +Connection tracking   |  4.3   |   YES  |
> PARTIAL
> >> | PARTIAL |
> >>  Tunnel - LISP |  NO|   YES  |NO
> >> |   NO|
> >>  Tunnel - STT  |  NO|   YES  |NO
> >> |   YES   |
> >>  Tunnel - GRE  |  3.11  |   YES  |YES
> >> |   YES   |
> >> diff --git a/NEWS b/NEWS
> >> index 4e81cad..fa367d2 100644
> >> --- a/NEWS
> >> +++ b/NEWS
> >> @@ -32,6 +32,8 @@ 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.
> >> + * Basic connection tracking for the userspace datapath (no
> ALG,
> >> +   fragmentation or NAT support yet)
> >> - ovs-benchmark: This utility has been removed due to lack of
> use
> >> and
> >>   bitrot.
> >> - ovs-appctl:
> >> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> >> index 33fd228..9cd985a 100644
> >> --- a/lib/dpif-netdev.c
> >> +++ b/lib/dpif-netdev.c
> >> @@ -33,6 +33,7 @@
> >>
> >>  #include "bitmap.h"
> >>  #include "cmap.h"
> >> +#include "conntrack.h"
> >>  #include "coverage.h"
> >>  #include "csum.h"
> >>  #include "dp-packet.h"
> >> @@ -89,9 +90,17 @@ static struct shash dp_netdevs
> >> OVS_GUARDED_BY(dp_netdev_mutex)
> >>
> >>  static struct vlog_rate_limit upcall_rl =
> VLOG_RATE_LIMIT_INIT(600,
> >> 600);
> >>
> >> +#define DP_NETDEV_CS_SUPPORTED_MASK (CS_NEW | CS_ESTABLISHED |
> >> CS_RELATED \
> >> + | CS_INVALID | CS_REPLY_DIR
> |
> >> CS_TRACKED)
> >> +#define DP_NETDEV_CS_UNSUPPORTED_MASK
> >> (~(uint32_t)DP_NETDEV_CS_SUPPORTED_MASK)
> >> +
> >>  static struct odp_support dp_netdev_support = {
> >>  .max_mpls_depth = SIZE_MAX,
> >>  .recirc = true,
> >> +.ct_state = true,
> >> +.ct_zone = true,
> >> +.ct_mark = true,
> >> +.ct_label = true,
> >>  };
> >>
> >>  /* Stores a miniflow with inline values */
> >> @@ -224,6 +233,8 @@ struct dp_netdev {
> >>  /* Cpu mask for pin of pmd threads. */
> >>  char *pmd_cmask;
> >>  uint64_t last_tnl_conf_seq;
> >> +
> >> +struct conntrack conntrack;
> >>  };
> >>
> >>  static struct dp_netdev_port *dp_netdev_lookup_port(const struct
> >> dp_netdev *dp,
> >> @@ -906,6 +917,8 @@ create_dp_netdev(const char *name, const
> struct
> >> dpif_class *class,
> >>  dp->upcall_aux = NULL;
> >>  dp->upcall_cb = NULL;
> >>
> >> +conntrack_init(>conntrack);
> >> +
> >>  cmap_init(>poll_threads);
> >>  ovs_mutex_init_recursive(>non_pmd_mutex);
> >>  ovsthread_key_create(>per_pmd_key, NULL);
> >> @@ -976,6 +989,8 @@ dp_netdev_free(struct dp_netdev *dp)
> >>  ovs_mutex_destroy(>non_pmd_mutex);
> >>

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

2016-05-26 Thread Returned mail

¨£aôlö£Û©[j©ülfkF¢R·¢¯ÁN2ÚãQ[ÀD(

74 matches

Mail list logo