Re: [ovs-dev] [PATCH] datapath-windows: Support to selectively compile targets

[Anand Kumar]

Hi,

My thoughts are with Shashank on this, it makes sense to have 1 configure and 1 
make command to build a particular target, instead of having flexibility to 
specify multiple targets.

Thanks,
Anand Kumar 

On 2/8/18, 10:56 AM, "ovs-dev-boun...@openvswitch.org on behalf of Shashank 
Ram"  wrote:






From: aserd...@ovn.org 
Sent: Thursday, February 8, 2018 10:43 AM
To: Shashank Ram; aserd...@ovn.org; d...@openvswitch.org
Subject: RE: [ovs-dev] [PATCH] datapath-windows: Support to selectively 
compile targets

Trimming the message a bit.

-Mesaj original-
De la: ovs-dev-boun...@openvswitch.org
[mailto:ovs-dev-boun...@openvswitch.org] În numele Shashank Ram
Trimis: Thursday, February 8, 2018 7:50 PM
Către: aserd...@ovn.org; d...@openvswitch.org
Subiect: Re: [ovs-dev] [PATCH] datapath-windows: Support to selectively
compile targets

Hi Alin, thanks for the review.
I personally feel we should be consistent and run configure, and have a
single make command to build both user space and kernel. What part did you
find complicated?
[Alin Serdean] I.e. if I configure to target 8. And after I need to target
10 I need to do a reconfigure (similar, for debug and or other platforms).
[SR]: In an automated environment, this shouldn't happen.
For local compilation, you should be able to manually compile the kernel.

The configure part is particularly slow on Windows.
For convenience the old part with selecting Debug/Release and
trying to build for all the compilers found in the system is still there, so
building both
userspace and kernel will still be in a single command.
I don't see a huge issue to specify two or more make commands to build a
particular target of the kernel
via the shell.
[SR]: I don't think its a big deal either, but its more convenient to run 1 
configure and 1
make command.

I prefer to keep this as is for now and wait for more reviews.

___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwIFBA=uilaK90D4TOVoH58JNXRgQ=Q5z9tBe-nAOpE7LIHSPV8uy5-437agMXvkeHHMkR8Us=fKK6KZRD0tZEfwHzLhMsabCH5aXzzYiRP-pJR20Xj9o=nEl_7Q-LhJ74AdsiY85DjA-kWy0uESr5DyFrWDQYKjs=


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] conntrack: Support conntrack flush by ct 5-tuple

[Darrell Ball]

Nice.

Acked-by: Darrell Ball 

On Mon, Feb 12, 2018 at 4:26 PM, Darrell Ball  wrote:

> Thanks Yi-hung
>
> I will try it out.
>
> Darrell
>
> On Mon, Feb 12, 2018 at 2:02 PM, Yi-Hung Wei  wrote:
>
>> This patch adds support of flushing a conntrack entry specified by the
>> conntrack 5-tuple in dpif-netdev.
>>
>> Signed-off-by: Yi-Hung Wei 
>> ---
>> Respin this patch since userspace conntrack now clears out the expectation
>> when a conntrack entry is deleted.
>> ---
>>  lib/conntrack.c  | 72 ++
>> ++
>>  lib/conntrack.h  |  3 ++
>>  lib/dpif-netdev.c|  2 +-
>>  tests/system-kmod-macros.at  |  8 -
>>  tests/system-traffic.at  |  1 -
>>  tests/system-userspace-macros.at | 10 --
>>  6 files changed, 76 insertions(+), 20 deletions(-)
>>
>> diff --git a/lib/conntrack.c b/lib/conntrack.c
>> index fe5fd0fe8be1..c05b3901d7af 100644
>> --- a/lib/conntrack.c
>> +++ b/lib/conntrack.c
>> @@ -2368,6 +2368,10 @@ delete_conn(struct conn *conn)
>>  free(conn);
>>  }
>>
>> +/* Convert a conntrack address 'a' into an IP address 'b' based on
>> 'dl_type'.
>> + *
>> + * Note that 'dl_type' should be either "ETH_TYPE_IP" or "ETH_TYPE_IPv6"
>> + * in network-byte order. */
>>  static void
>>  ct_endpoint_to_ct_dpif_inet_addr(const struct ct_addr *a,
>>   union ct_dpif_inet_addr *b,
>> @@ -2380,6 +2384,22 @@ ct_endpoint_to_ct_dpif_inet_addr(const struct
>> ct_addr *a,
>>  }
>>  }
>>
>> +/* Convert an IP address 'a' into a conntrack address 'b' based on
>> 'dl_type'.
>> + *
>> + * Note that 'dl_type' should be either "ETH_TYPE_IP" or "ETH_TYPE_IPv6"
>> + * in network-byte order. */
>> +static void
>> +ct_dpif_inet_addr_to_ct_endpoint(const union ct_dpif_inet_addr *a,
>> + struct ct_addr *b,
>> + ovs_be16 dl_type)
>> +{
>> +if (dl_type == htons(ETH_TYPE_IP)) {
>> +b->ipv4_aligned = a->ip;
>> +} else if (dl_type == htons(ETH_TYPE_IPV6)){
>> +b->ipv6_aligned = a->in6;
>> +}
>> +}
>> +
>>  static void
>>  conn_key_to_tuple(const struct conn_key *key, struct ct_dpif_tuple
>> *tuple)
>>  {
>> @@ -2405,6 +2425,35 @@ conn_key_to_tuple(const struct conn_key *key,
>> struct ct_dpif_tuple *tuple)
>>  }
>>
>>  static void
>> +tuple_to_conn_key(const struct ct_dpif_tuple *tuple, uint16_t zone,
>> +  struct conn_key *key)
>> +{
>> +if (tuple->l3_type == AF_INET) {
>> +key->dl_type = htons(ETH_TYPE_IP);
>> +} else if (tuple->l3_type == AF_INET6) {
>> +key->dl_type = htons(ETH_TYPE_IPV6);
>> +}
>> +key->nw_proto = tuple->ip_proto;
>> +ct_dpif_inet_addr_to_ct_endpoint(>src, >src.addr,
>> + key->dl_type);
>> +ct_dpif_inet_addr_to_ct_endpoint(>dst, >dst.addr,
>> + key->dl_type);
>> +
>> +if (tuple->ip_proto == IPPROTO_ICMP || tuple->ip_proto ==
>> IPPROTO_ICMPV6) {
>> +key->src.icmp_id = tuple->icmp_id;
>> +key->src.icmp_type = tuple->icmp_type;
>> +key->src.icmp_code = tuple->icmp_code;
>> +key->dst.icmp_id = tuple->icmp_id;
>> +key->dst.icmp_type = reverse_icmp_type(tuple->icmp_type);
>> +key->dst.icmp_code = tuple->icmp_code;
>> +} else {
>> +key->src.port = tuple->src_port;
>> +key->dst.port = tuple->dst_port;
>> +}
>> +key->zone = zone;
>> +}
>> +
>> +static void
>>  conn_to_ct_dpif_entry(const struct conn *conn, struct ct_dpif_entry
>> *entry,
>>long long now, int bkt)
>>  {
>> @@ -2517,6 +2566,29 @@ conntrack_flush(struct conntrack *ct, const
>> uint16_t *zone)
>>  }
>>
>>  int
>> +conntrack_flush_tuple(struct conntrack *ct, const struct ct_dpif_tuple
>> *tuple,
>> +  uint16_t zone)
>> +{
>> +struct conn_lookup_ctx ctx;
>> +int error = 0;
>> +
>> +memset(, 0, sizeof(ctx));
>> +tuple_to_conn_key(tuple, zone, );
>> +ctx.hash = conn_key_hash(, ct->hash_basis);
>> +unsigned bucket = hash_to_bucket(ctx.hash);
>> +
>> +ct_lock_lock(>buckets[bucket].lock);
>> +conn_key_lookup(>buckets[bucket], , time_msec());
>> +if (ctx.conn) {
>> +conn_clean(ct, ctx.conn, >buckets[bucket]);
>> +} else {
>> +error = ENOENT;
>> +}
>> +ct_lock_unlock(>buckets[bucket].lock);
>> +return error;
>> +}
>> +
>> +int
>>  conntrack_set_maxconns(struct conntrack *ct, uint32_t maxconns)
>>  {
>>  atomic_store_relaxed(>n_conn_limit, maxconns);
>> diff --git a/lib/conntrack.h b/lib/conntrack.h
>> index ac650304a41f..e3a5dcc8023f 100644
>> --- a/lib/conntrack.h
>> +++ b/lib/conntrack.h
>> @@ -109,6 +109,7 @@ struct conntrack_dump {
>>  };
>>
>>  struct ct_dpif_entry;
>> +struct ct_dpif_tuple;
>>
>>  int conntrack_dump_start(struct conntrack *, 

[ovs-dev] Cómo Convertir Clientes en Fans

[Disney - Webinar]

Solicite AHORA MISMO el temario con toda la información de este EXCLUSIVO 
EVENTO PRESIONE AQUI o responda "Disney"+TELÉFONO + NOMBRE
045 + 5515546630 


¿Cómo Convertir Clientes en Fans? The Disney Way
Febrero 20 - webinar Interactivo
 
 


Las empresas resistentes al cambio y poco adaptativas con el entorno y con la 
manera en la que el mundo se va reordenando, tanto en la comunicación y 
relación con clientes, como de manera interna en la organización, se ponen un 
pie en el camino que siguen las empresas que perduran y crecen actualmente. 
Disney es la opción ideal y el modelo excepcional que cualquier empresa puede 
poner en práctica para comenzar a ganar fans.
 
Inscríbase Ahora, el cupo es limitado
 Atte. el equipo comercial




___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [patch v5 00/11] Userspace datapath: Add fragmentation support.

[Darrell Ball]

On Fri, Feb 9, 2018 at 1:35 PM, Aaron Conole  wrote:

> Hi Darrell,
>
> Darrell Ball  writes:
>
> > Fragmentation support for userspace datapath conntrack is added; both
> > v4 and v6 are supported. See the patches for additional details.
>
> Very pumped about this!


> I went to start reviewing this, but found out that 04/ didn't apply
> correctly.  No problem, I'll proceed - just figured I'd let you know
> that:



The merge conflict in NEWS was due to 2 subsequent applies on Feb 6, while
the series was posted on Feb 4.



>
>   1. I'm looking at it :)
>


Thanks Aaron

Darrell



>   2. it'll need at least one more spin (but no need to rush that since
>  I'll move myself past the error)


> Thanks,
> -Aaron
>
> > v4->v5: Added a sub-feature to optionally dump fragmentation lists.
> > This is useful for DOS forensics and debugging.
> >
> > The testing coverage was also extended including checking
> > more counters and frag list occupancies.
> >
> > Fixed a few bugs:
> > 1/ Handle dpdk mempool source restrictions for a batch of
> >packets from multiple sources; this also brings in a purge
> >frag list function to handle pathological cases of stuck
> frags.
> > 2/ ipf_destroy was missing packet frees for frag lists.
> > 3/ A setting of CS_INVALID was missing for expired packets -
> >I mentioned this earlier for version 4.
> >
> > Some enhancements and coding standards changes for Patch 3.
> >
> > v3->v4: Add V6 support to the patches.
> > Fix possible race cleanup bug when the user disables
> >fragmentation and there are list occupancies, not cleaned up
> >yet.
> > Add missed orig tuple fields for copy from reassembled packet
> > to fragments.
> > Fix an fragment list increment check - shoiuld have been "> 0"
> > rather then "!= 0".
> > Fix max frags calculation in case of theoretical corner case.
> > Add proper lock annotations.
> > Made some other improvements while adding V6 support.
> >
> > v2->v3: Patch 2 was updated:
> > Remove "XXX" todo items by implementing the ones needed,
> > including realloc frag_list contexts to save memory.
> > Fix related bug with max_frag_list_size when min_frag_size is
> > reconfigured.
> >
> > Tighten ip_tot_len sanity check for reassembled packets which
> > was more loose than intended.
> >
> > Add another sanity check for fragment ip_tot_len; even though
> > it be redundant, add for completeness.
> >
> > v1->v2: Few fixes, improvements and cleanups.
> >
> > Darrell Ball (11):
> >   dp-packet: Add const qualifiers for checksum apis.
> >   flow: Enhance parse_ipv6_ext_hdrs.
> >   Userspace datapath: Add fragmentation handling.
> >   conntrack: Support fragmentation.
> >   ipf: Add command to enable fragmentation handling.
> >   ipf: Add set minimum fragment size command.
> >   ipf: Add set maximum fragments supported command.
> >   ipf: Add command to get fragmentation handling status.
> >   ipf: Enhance ipf_get_status.
> >   tests: Add missed local stack checks.
> >   tests: Enable fragmentation for userspace datapath.
> >
> >  NEWS |   10 +
> >  include/sparse/netinet/ip6.h |1 +
> >  lib/automake.mk  |2 +
> >  lib/conntrack.c  |   10 +-
> >  lib/ct-dpif.c|   69 ++
> >  lib/ct-dpif.h|   13 +
> >  lib/dp-packet.h  |4 +-
> >  lib/dpctl.c  |  216 ++
> >  lib/dpctl.man|   32 +
> >  lib/dpif-netdev.c|   83 +++
> >  lib/dpif-netlink.c   |7 +
> >  lib/dpif-provider.h  |   18 +
> >  lib/flow.c   |   23 +-
> >  lib/flow.h   |3 +-
> >  lib/ipf.c| 1390 ++
> 
> >  lib/ipf.h|   86 +++
> >  tests/system-kmod-macros.at  |   30 +-
> >  tests/system-traffic.at  |   45 +-
> >  tests/system-userspace-macros.at |  125 +++-
> >  19 files changed, 2129 insertions(+), 38 deletions(-)
> >  create mode 100644 lib/ipf.c
> >  create mode 100644 lib/ipf.h
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] conntrack: Support conntrack flush by ct 5-tuple

[Darrell Ball]

Thanks Yi-hung

I will try it out.

Darrell

On Mon, Feb 12, 2018 at 2:02 PM, Yi-Hung Wei  wrote:

> This patch adds support of flushing a conntrack entry specified by the
> conntrack 5-tuple in dpif-netdev.
>
> Signed-off-by: Yi-Hung Wei 
> ---
> Respin this patch since userspace conntrack now clears out the expectation
> when a conntrack entry is deleted.
> ---
>  lib/conntrack.c  | 72 ++
> ++
>  lib/conntrack.h  |  3 ++
>  lib/dpif-netdev.c|  2 +-
>  tests/system-kmod-macros.at  |  8 -
>  tests/system-traffic.at  |  1 -
>  tests/system-userspace-macros.at | 10 --
>  6 files changed, 76 insertions(+), 20 deletions(-)
>
> diff --git a/lib/conntrack.c b/lib/conntrack.c
> index fe5fd0fe8be1..c05b3901d7af 100644
> --- a/lib/conntrack.c
> +++ b/lib/conntrack.c
> @@ -2368,6 +2368,10 @@ delete_conn(struct conn *conn)
>  free(conn);
>  }
>
> +/* Convert a conntrack address 'a' into an IP address 'b' based on
> 'dl_type'.
> + *
> + * Note that 'dl_type' should be either "ETH_TYPE_IP" or "ETH_TYPE_IPv6"
> + * in network-byte order. */
>  static void
>  ct_endpoint_to_ct_dpif_inet_addr(const struct ct_addr *a,
>   union ct_dpif_inet_addr *b,
> @@ -2380,6 +2384,22 @@ ct_endpoint_to_ct_dpif_inet_addr(const struct
> ct_addr *a,
>  }
>  }
>
> +/* Convert an IP address 'a' into a conntrack address 'b' based on
> 'dl_type'.
> + *
> + * Note that 'dl_type' should be either "ETH_TYPE_IP" or "ETH_TYPE_IPv6"
> + * in network-byte order. */
> +static void
> +ct_dpif_inet_addr_to_ct_endpoint(const union ct_dpif_inet_addr *a,
> + struct ct_addr *b,
> + ovs_be16 dl_type)
> +{
> +if (dl_type == htons(ETH_TYPE_IP)) {
> +b->ipv4_aligned = a->ip;
> +} else if (dl_type == htons(ETH_TYPE_IPV6)){
> +b->ipv6_aligned = a->in6;
> +}
> +}
> +
>  static void
>  conn_key_to_tuple(const struct conn_key *key, struct ct_dpif_tuple *tuple)
>  {
> @@ -2405,6 +2425,35 @@ conn_key_to_tuple(const struct conn_key *key,
> struct ct_dpif_tuple *tuple)
>  }
>
>  static void
> +tuple_to_conn_key(const struct ct_dpif_tuple *tuple, uint16_t zone,
> +  struct conn_key *key)
> +{
> +if (tuple->l3_type == AF_INET) {
> +key->dl_type = htons(ETH_TYPE_IP);
> +} else if (tuple->l3_type == AF_INET6) {
> +key->dl_type = htons(ETH_TYPE_IPV6);
> +}
> +key->nw_proto = tuple->ip_proto;
> +ct_dpif_inet_addr_to_ct_endpoint(>src, >src.addr,
> + key->dl_type);
> +ct_dpif_inet_addr_to_ct_endpoint(>dst, >dst.addr,
> + key->dl_type);
> +
> +if (tuple->ip_proto == IPPROTO_ICMP || tuple->ip_proto ==
> IPPROTO_ICMPV6) {
> +key->src.icmp_id = tuple->icmp_id;
> +key->src.icmp_type = tuple->icmp_type;
> +key->src.icmp_code = tuple->icmp_code;
> +key->dst.icmp_id = tuple->icmp_id;
> +key->dst.icmp_type = reverse_icmp_type(tuple->icmp_type);
> +key->dst.icmp_code = tuple->icmp_code;
> +} else {
> +key->src.port = tuple->src_port;
> +key->dst.port = tuple->dst_port;
> +}
> +key->zone = zone;
> +}
> +
> +static void
>  conn_to_ct_dpif_entry(const struct conn *conn, struct ct_dpif_entry
> *entry,
>long long now, int bkt)
>  {
> @@ -2517,6 +2566,29 @@ conntrack_flush(struct conntrack *ct, const
> uint16_t *zone)
>  }
>
>  int
> +conntrack_flush_tuple(struct conntrack *ct, const struct ct_dpif_tuple
> *tuple,
> +  uint16_t zone)
> +{
> +struct conn_lookup_ctx ctx;
> +int error = 0;
> +
> +memset(, 0, sizeof(ctx));
> +tuple_to_conn_key(tuple, zone, );
> +ctx.hash = conn_key_hash(, ct->hash_basis);
> +unsigned bucket = hash_to_bucket(ctx.hash);
> +
> +ct_lock_lock(>buckets[bucket].lock);
> +conn_key_lookup(>buckets[bucket], , time_msec());
> +if (ctx.conn) {
> +conn_clean(ct, ctx.conn, >buckets[bucket]);
> +} else {
> +error = ENOENT;
> +}
> +ct_lock_unlock(>buckets[bucket].lock);
> +return error;
> +}
> +
> +int
>  conntrack_set_maxconns(struct conntrack *ct, uint32_t maxconns)
>  {
>  atomic_store_relaxed(>n_conn_limit, maxconns);
> diff --git a/lib/conntrack.h b/lib/conntrack.h
> index ac650304a41f..e3a5dcc8023f 100644
> --- a/lib/conntrack.h
> +++ b/lib/conntrack.h
> @@ -109,6 +109,7 @@ struct conntrack_dump {
>  };
>
>  struct ct_dpif_entry;
> +struct ct_dpif_tuple;
>
>  int conntrack_dump_start(struct conntrack *, struct conntrack_dump *,
>   const uint16_t *pzone, int *);
> @@ -116,6 +117,8 @@ int conntrack_dump_next(struct conntrack_dump *,
> struct ct_dpif_entry *);
>  int conntrack_dump_done(struct conntrack_dump *);
>
>  int conntrack_flush(struct conntrack *, 

[ovs-dev] [RFC PATCH v2 6/6] Conntrack: Add UDP support for SIP.

[Tiago Lam]

The network protocol was already being verified in handle_sip in order
to check the transport was indeed TCP. This commit adds support for UDP
by checking the network protocol, and in case of UDP, a new function,
handle_sip_udp, is called to handle the UDP traffic. This function also
takes into account the framing of the SIP message under UDP.

An end-to-end test has been added to system-traffic.at to cover the UDP
transport. Similar to the TCP case, it also sets up two NS', NS1 and
NS2, sets up the expected flows and then verifies that the traffic was
handled correctly. More tests have also been added to test-sip.c to
validate the correct handling of the UDP framing (if a "Content-Length"
header exists then it must be taken into account).

Signed-off-by: Tiago Lam 
---
 lib/conntrack-sip.c |  94 +++-
 lib/conntrack-sip.h |   2 +
 lib/conntrack.c |   4 ++
 tests/system-traffic.at |  71 +
 tests/test-sip.c| 160 +++-
 5 files changed, 328 insertions(+), 3 deletions(-)

diff --git a/lib/conntrack-sip.c b/lib/conntrack-sip.c
index c4ae8dc50..129ee5e7f 100644
--- a/lib/conntrack-sip.c
+++ b/lib/conntrack-sip.c
@@ -777,6 +777,95 @@ sip_parse_tcp_msg(char *sip, size_t sip_len) {
 return out_msg;
 }
 
+/* Same as 'sip_parse_tcp' function  above, but for SIP messages transported
+ * over UDP. Given a pointer to the beginning of a SIP message that has been
+ * transmitted over UDP, parses the SIP message. In case the message is not
+ * well framed or considered invalid, NULL is returned.
+ *
+ * 'sip' should point to the beginning of the SIP message.
+ * 'sip_len' the size of the whole SIP message.
+ *
+ * Returns a 'sip_msg' struct, which the caller is responsible for freeing.
+ * The returned 'sip_msg' has pointers to the parsed message-line, message-
+ * header, and message-body, as well as appropriate lengths set */
+struct sip_msg *
+sip_parse_udp(char *sip, size_t sip_len) {
+size_t orig_len = sip_len;
+size_t cur_len = orig_len;
+
+struct sip_strt_ln *strt_ln = sip_parse_strt_ln(sip, sip_len);
+if (strt_ln == NULL) {
+return NULL;
+}
+
+/* Pointer to the beginning of SIP message-header */
+char *msg_hdr = sip_msg_hdr(sip, _len);
+
+size_t vlen;
+int cont_len;
+char *val = sip_get_hdr_val(msg_hdr, sip_len, SIPH_CONT_LEN, );
+if (val == NULL) {
+cont_len = 0;
+} else {
+cont_len = sip_hdr_to_uint(val, vlen);
+if (cont_len < 0) {
+return NULL;
+}
+}
+
+/* Pointer to the beginning of SIP message-body */
+char *msg_bdy = sip_msg_bdy(msg_hdr, _len);
+if (msg_bdy == NULL) {
+return NULL;
+}
+
+cur_len -= sip_len;
+
+size_t miss_len;
+if (cont_len == 0) {
+miss_len = orig_len - cur_len;
+} else {
+/* If a "Content-Length" header exists "the message body is assumed to
+ * contain that many bytes" ("18.3 Framing", rfc3261) */
+size_t exp_len = cur_len + cont_len;
+if (exp_len > orig_len) {
+/* Error: "Content-Length" points to more data than available */
+return NULL;
+} else {
+/* rfc3261, additional bytes in the transport packet beyond th end
+ * of the body MUST be discarded */
+miss_len = exp_len - cur_len;
+}
+}
+
+/* At most, UDP transports a single SIP message */
+struct sip_msg *out_msg = xmalloc(sizeof(*out_msg));
+out_msg->strt_ln = strt_ln;
+out_msg->msg_hdr = msg_hdr;
+out_msg->msg_bdy = msg_bdy;
+out_msg->bdy_len = miss_len;
+
+return out_msg;
+}
+
+static void
+handle_sip_udp(struct conntrack *ct, struct dp_packet *pkt,
+   const struct conn *conn, long long now) {
+struct udp_header *uh = dp_packet_l4(pkt);
+size_t udp_len = ntohs(uh->udp_len) - UDP_HEADER_LEN;
+char *udp_hdr = (char *) uh;
+
+/* Move to beginning of UDP payload, where the SIP payload is */
+char *sip = udp_hdr + UDP_HEADER_LEN;
+size_t sip_len = udp_len;
+
+struct sip_msg *out_msg = sip_parse_udp(sip, sip_len);
+
+sip_process_msg(ct, pkt, conn, now, out_msg);
+
+free(out_msg);
+}
+
 /* Parses SIP messages over TCP. It relies on the "Content-Length" header to
  * know the full length of each SIP message. It returns a list of sip_msg
  * structs, with pointers to each parsed message-line, message-header, and
@@ -842,8 +931,6 @@ handle_sip_tcp(struct conntrack *ct, struct dp_packet *pkt,
 
 /* XXX Only handles IPv4 for now, must include IPv6 in the future */
 /* XXX NAT support hasn't been properly tested yet */
-/* XXX No support for SIP over UDP either (not tested at least), which might
- * be required in the future */
 void
 handle_sip(struct conntrack *ct,
const struct conn_lookup_ctx *ctx OVS_UNUSED,
@@ -861,6 +948,9 @@ handle_sip(struct conntrack *ct,
   

[ovs-dev] [RFC PATCH v2 5/6] Conntrack: Add SIP end-to-end and unit tests.

[Tiago Lam]

End-to-end tests have been added to system-traffic.at. They set up a NS1
that acts as a UAS and another NS2 that acts as a UAC, set up the
appropriate flows in each direction and finally verify if the traffic
between the two NS' is as expected. These tests make use of the SIPp
tool and the scenarios needed by SIPp have been added to the new sipp/
folder under tests/.

Unit tests have also been added to test-sip.c, and are being called from
conntrack-sip.at. These tests call functions like sip_parse_sdp,
sip_parse_strt_line and sip_parse_tcp, passing both valid and invalid
inputs, then comparing with the expected results. This includes tests
for validating the supported TCP framing.

Signed-off-by: Tiago Lam 
---
 tests/atlocal.in   |   3 +
 tests/automake.mk  |   8 +
 tests/conntrack-sip.at |   7 +
 tests/sipp/uac_happy_case_scenario.xml | 126 +
 tests/sipp/uas_happy_case_scenario.xml | 125 +
 tests/system-traffic.at|  71 +++
 tests/test-sip.c   | 327 +
 tests/testsuite.at |   1 +
 8 files changed, 668 insertions(+)
 create mode 100644 tests/conntrack-sip.at
 create mode 100644 tests/sipp/uac_happy_case_scenario.xml
 create mode 100644 tests/sipp/uas_happy_case_scenario.xml
 create mode 100644 tests/test-sip.c

diff --git a/tests/atlocal.in b/tests/atlocal.in
index 55f9333ee..023337b5c 100644
--- a/tests/atlocal.in
+++ b/tests/atlocal.in
@@ -168,6 +168,9 @@ fi
 # Set HAVE_TCPDUMP
 find_command tcpdump
 
+# Set HAVE_SIPP
+find_command sipp
+
 CURL_OPT="-g -v --max-time 1 --retry 2 --retry-delay 1 --connect-timeout 1"
 
 # Turn off proxies.
diff --git a/tests/automake.mk b/tests/automake.mk
index 18698ebc3..fc2efe255 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -94,6 +94,7 @@ TESTSUITE_AT = \
tests/vlog.at \
tests/vtep-ctl.at \
tests/auto-attach.at \
+   tests/conntrack-sip.at \
tests/ovn.at \
tests/ovn-northd.at \
tests/ovn-nbctl.at \
@@ -335,6 +336,7 @@ tests_ovstest_SOURCES = \
tests/test-ccmap.c \
tests/test-cmap.c \
tests/test-conntrack.c \
+   tests/test-sip.c \
tests/test-csum.c \
tests/test-flows.c \
tests/test-hash.c \
@@ -405,6 +407,11 @@ PYCOV_CLEAN_FILES += $(CHECK_PYFILES:.py=.py,cover) 
.coverage
 
 FLAKE8_PYFILES += $(CHECK_PYFILES)
 
+# SIPP scenarios
+EXTRA_DIST += \
+   tests/sipp/uac_happy_case_scenario.xml \
+   tests/sipp/uas_happy_case_scenario.xml
+
 if HAVE_OPENSSL
 TESTPKI_FILES = \
tests/testpki-cacert.pem \
@@ -446,4 +453,5 @@ CLEAN_LOCAL += clean-pki
 clean-pki:
rm -f tests/pki/stamp
rm -rf tests/pki
+
 endif
diff --git a/tests/conntrack-sip.at b/tests/conntrack-sip.at
new file mode 100644
index 0..17eff915c
--- /dev/null
+++ b/tests/conntrack-sip.at
@@ -0,0 +1,7 @@
+AT_BANNER([conntrack-sip unit tests])
+
+AT_SETUP([conntrack-sip])
+AT_KEYWORDS([conntrack-sip])
+AT_CHECK(ovstest test-sip, [], [ignore], [ignore])
+
+AT_CLEANUP
diff --git a/tests/sipp/uac_happy_case_scenario.xml 
b/tests/sipp/uac_happy_case_scenario.xml
new file mode 100644
index 0..ee728dfc1
--- /dev/null
+++ b/tests/sipp/uac_happy_case_scenario.xml
@@ -0,0 +1,126 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+  
+  
+
+  
+
+  
+  
+
+  
+  
+
+  
+  
+
+  
+  
+  
+  
+  
+
+  
+  
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+  
+  
+
+  
+  
+
+  
+
+  
+  
+
+  
+  
+
+  
+  
+
+
diff --git a/tests/sipp/uas_happy_case_scenario.xml 
b/tests/sipp/uas_happy_case_scenario.xml
new file mode 100644
index 0..beb2110c2
--- /dev/null
+++ b/tests/sipp/uas_happy_case_scenario.xml
@@ -0,0 +1,125 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+  
+  
+  
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+  
+
+  
+
+  
+  
+  
+
+  
+  
+
+  
+
+  
+
+  
+  
+  
+
+
+  
+  
+
+  
+  
+
+
diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index dbd56405d..e8dba721a 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -2870,6 +2870,77 @@ 
udp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=,dport=),reply=(src=
 OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
+dnl Setups two namespaces, at_ns0 and at_ns1, connected to a bridge, br0, and
+dnl runs sipp in both in the following form:
+dnl - at_ns0 loads an UAS scenario and waits for requests;
+dnl - at_ns1 loads an UAC scenario, which will connect to at_ns0.
+dnl
+dnl Aside from RTP (which is over UDP), this tests sends SIP over TCP over
+dnl IPv4 and no NAT is performed.
+AT_SETUP([conntrack - SIP over TCP over IPv4])
+AT_SKIP_IF([test $HAVE_SIPP = no])
+CHECK_CONNTRACK()
+CHECK_CONNTRACK_ALG()
+
+OVS_TRAFFIC_VSWITCHD_START()
+
+ADD_NAMESPACES(at_ns0, at_ns1)
+
+ADD_VETH(p0, at_ns0, br0, "10.0.1.10/24")
+NS_CHECK_EXEC([at_ns0], 

[ovs-dev] [RFC PATCH v2 4/6] Conntrack: Add initial support for new SIP Alg.

[Tiago Lam]

Handle_sip, in conntrack-sip.c, is the new function handler that handles
the SIP messages received in the userspace conntrack (detected in
process_one).  It parses the SIP messages (and SDPs) using the newly
introduced SIP API (conntrack-sip.{c,h}) and accordingly creates the
expectations necessary to let the RTP traffic through.  To identify the
new SIP Alg, a new IPPROTO_SIP has also been introduced, which maps to
port 5060, the SIP assigned port.

As of now, this preliminary support mainly handles the following happy
case, exchanged between a UAC and UAS:
- UAC > UAS | SIP INVITE (SDP offer);
- UAC < UAS | SIP 200(SDP answer);
- UAC > UAS | SIP ACK;
- UAC > UAS | SIP BYE;
- UAC < UAS | SIP 200;
It also assumes the SIP messages are coming over TCP and IPv4 (although
SIP's main usage is over UDP).

This integration has been tested manually by setting the following
flows, which let's tcp traffic from port 1 to flow to port 0, but only
+ESTABLISHED or +RELATED traffic on the opposite direction (from port 0
to port 1). It also allows UDP +RELATED to pass through in both
directions (which is needed for the RTP packets):
- table=0,priority=1,action=drop
- table=0,priority=10,arp,action=normal
- table=0,priority=10,icmp,action=normal
- table=0,priority=100,in_port=1,tcp,action=ct(alg=sip,commit),0
- table=0,priority=100,in_port=0,tcp,action=ct(table=1)
- table=0,priority=100,in_port=1,udp,action=ct(table=2)
- table=0,priority=100,in_port=0,udp,action=ct(table=2)
- table=1,in_port=0,tcp,ct_state=+trk+est,action=1
- table=1,in_port=0,tcp,ct_state=+trk+rel,action=1
- table=2,in_port=0,udp,ct_state=+rel,action=1
- table=2,in_port=1,udp,ct_state=+rel,action=0

It is also worth noting that although basic TCP framing support has been
added, it however will fail to work when a single SIP message might span
multiple TCP packets.

Signed-off-by: Tiago Lam 
---
 include/openvswitch/ofp-actions.h |   4 +
 lib/conntrack-private.h   |  30 +++
 lib/conntrack-sip.c   | 518 +-
 lib/conntrack-sip.h   |  76 +-
 lib/conntrack.c   |  78 +++---
 lib/ofp-parse.c   |   5 +
 ofproto/ofproto-dpif-xlate.c  |   3 +
 7 files changed, 609 insertions(+), 105 deletions(-)

diff --git a/include/openvswitch/ofp-actions.h 
b/include/openvswitch/ofp-actions.h
index cba027b1d..558861262 100644
--- a/include/openvswitch/ofp-actions.h
+++ b/include/openvswitch/ofp-actions.h
@@ -606,6 +606,10 @@ enum nx_conntrack_flags {
 #define IPPORT_TFTP  69
 #endif
 
+#if !defined(IPPORT_SIP)
+#define IPPORT_SIP  5060
+#endif
+
 /* OFPACT_CT.
  *
  * Used for NXAST_CT. */
diff --git a/lib/conntrack-private.h b/lib/conntrack-private.h
index bf1d0773b..68afd3f3d 100644
--- a/lib/conntrack-private.h
+++ b/lib/conntrack-private.h
@@ -57,6 +57,23 @@ struct conn_key {
 uint8_t nw_proto;
 };
 
+struct conn_lookup_ctx {
+struct conn_key key;
+struct conn *conn;
+uint32_t hash;
+bool reply;
+bool icmp_related;
+};
+
+enum ftp_ctl_pkt {
+/* Control packets with address and/or port specifiers. */
+CT_FTP_CTL_INTEREST,
+/* Control packets without address and/or port specifiers. */
+CT_FTP_CTL_OTHER,
+CT_FTP_CTL_INVALID,
+};
+
+
 struct nat_conn_key_node {
 struct hmap_node node;
 struct conn_key key;
@@ -107,6 +124,8 @@ struct conn {
 uint8_t seq_skew_dir;
 /* True if alg data connection. */
 uint8_t alg_related;
+/* SIP specific data */
+struct sip_alg_data *sip_alg;
 };
 
 enum ct_update_res {
@@ -139,6 +158,17 @@ extern struct ct_l4_proto ct_proto_icmp6;
 
 extern long long ct_timeout_val[];
 
+void
+expectation_create_outband(struct conntrack *ct, struct ct_addr src_addr,
+   struct ct_addr dst_addr, ovs_be16 dst_port,
+   const struct conn *master_conn, bool reply,
+   bool src_ip_wc, bool skip_nat, uint8_t nw_proto);
+
+uint32_t conn_key_hash(const struct conn_key *, uint32_t basis);
+struct conn *
+conn_lookup(struct conntrack *ct, const struct conn_key *key, long long now);
+unsigned hash_to_bucket(uint32_t hash);
+
 static inline void
 conn_init_expiration(struct conntrack_bucket *ctb, struct conn *conn,
 enum ct_timeout tm, long long now)
diff --git a/lib/conntrack-sip.c b/lib/conntrack-sip.c
index 7239bdad6..c4ae8dc50 100644
--- a/lib/conntrack-sip.c
+++ b/lib/conntrack-sip.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2017 Nicira, Inc.
+ * Copyright (c) 2018 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -54,34 +54,26 @@ enum sip_mthd sip_mthd_to_enum(char *mthd) {
  * Returns false to anything that falls outside of the ranges above, and true
  * otherwise. */
 bool is_valid_status(uint32_t status) {
-if ((status >= 100 && status < 200) ||
- 

[ovs-dev] [RFC PATCH v2 1/6] Conntrack: Add new API for future SIP Alg.

[Tiago Lam]

The new API (in conntrack-sip.h and conntrack-sip.c) defines preliminary
functions, helpers and strucures to move through and parse SIP messages,
including SDP in the message bodies, if present.

Note that this is still a preliminary version of the API, and future
work is still needed to improve the SIP and SDP handling. When parsing
an SDP, for example, the order of the 'm', 'c' and 'o' sections is not
enforced, and only the ports and IP addresses are stored at the moment.

This API will be used by a future commit in order to implement the new
SIP Alg in userspace conntrack.

Signed-off-by: Tiago Lam 
---
 lib/automake.mk |   2 +
 lib/conntrack-sip.c | 477 
 lib/conntrack-sip.h | 112 
 3 files changed, 591 insertions(+)
 create mode 100644 lib/conntrack-sip.c
 create mode 100644 lib/conntrack-sip.h

diff --git a/lib/automake.mk b/lib/automake.mk
index 38d2a999d..1afdb5756 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -51,6 +51,8 @@ lib_libopenvswitch_la_SOURCES = \
lib/connectivity.h \
lib/conntrack-icmp.c \
lib/conntrack-private.h \
+   lib/conntrack-sip.c \
+   lib/conntrack-sip.h \
lib/conntrack-tcp.c \
lib/conntrack-other.c \
lib/conntrack.c \
diff --git a/lib/conntrack-sip.c b/lib/conntrack-sip.c
new file mode 100644
index 0..7239bdad6
--- /dev/null
+++ b/lib/conntrack-sip.c
@@ -0,0 +1,477 @@
+/*
+ * Copyright (c) 2017 Nicira, Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at:
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+
+#include "conntrack-sip.h"
+#include "dp-packet.h"
+#include "util.h"
+
+enum sip_mthd sip_mthd_to_enum(char *mthd) {
+if (mthd == NULL) {
+return INVALID;
+}
+
+if (!strcmp(mthd, "INVITE")) {
+return INVITE;
+} else if (!strcmp(mthd, "REGISTER")) {
+return REGISTER;
+} else if (!strcmp(mthd, "ACK")) {
+return ACK;
+} else if (!strcmp(mthd, "CANCEL")) {
+return CANCEL;
+} else if (!strcmp(mthd, "BYE")) {
+return BYE;
+} else if (!strcmp(mthd, "OPTIONS")) {
+return OPTIONS;
+}
+
+return INVALID;
+}
+/* A valid SIP status falls in between the following ranges (rfc3261):
+ * - 1xx: Provisional;
+ * - 2xx: Success;
+ * - 3xx: Redirection;
+ * - 4xx: Client Error;
+ * - 5xx: Server Error;
+ * - 6xx: Global Failure.
+ *
+ * Returns false to anything that falls outside of the ranges above, and true
+ * otherwise. */
+bool is_valid_status(uint32_t status) {
+if ((status >= 100 && status < 200) ||
+(status >= 200 && status < 300) ||
+(status >= 300 && status < 400) ||
+(status >= 400 && status < 500) ||
+(status >= 500 && status < 600) ||
+(status >= 600 && status < 700)) {
+return true;
+}
+
+return false;
+}
+
+/* Find and validate the beginning of the CRLF ending, returning a pointer to
+ * the found CR, or NULL otherwise. */
+char * sip_ln_find_crlf(char *sip, size_t len) {
+if (sip == NULL) {
+return NULL;
+}
+
+char *cr = memchr(sip, '\r', len);
+if (cr == NULL) {
+return NULL;
+}
+char *lf = memchr(sip, '\n', len);
+if (lf == NULL) {
+return NULL;
+}
+
+if (lf - cr != 1) {
+return NULL;
+}
+
+return cr;
+}
+
+/* Returns the size of the line until the next CRLF ending (not inclusive). If
+ * CRLF is not found it returns -1. */
+size_t sip_ln_len(char *sip, size_t len) {
+char *cr = sip_ln_find_crlf(sip, len);
+if (cr == NULL) {
+return -1;
+}
+
+return cr - sip;
+}
+
+/* Ignores the next CRLF ending and moves to CRLF + 1. After returning, 'sip'
+ * is modified to point to the next line after CRLF (CRLF + 1), and 'len' has
+ * been updated accordingly. If CRLF is not found, 'sip' and 'len' are
+ * untouched */
+void sip_ln_skip(char **sip, size_t *len) {
+char *cr = sip_ln_find_crlf(*sip, *len);
+if (cr == NULL) {
+return;
+}
+size_t sz = cr - *sip;
+*sip += sz + 2;
+*len -= sz + 2;
+}
+
+/* Iterate through each word in the line at 'sip', where each word is divided
+ * by the space char ' ', and store the resulting word in 'dst', if not NULL.
+ *
+ * After returning 'sip' is pointing to the next word in the line, and 'len'
+ * has been updated accordingly. */
+bool sip_ln_cpy_nxt_word(char **sip, size_t *len, char **dst) {
+char 

[ovs-dev] [RFC PATCH v2 3/6] Conntrack: Add alg to alg_exp_node struct.

[Tiago Lam]

In certain protocols, such as SIP, infering if the data connection
belongs to a specific protocol might not be feasible, from the used
addresses and ports alone. The data connection may have a different
network transport protocol, src/dst addresses and/or src/dst ports than
the control connection.

Instead, this commit adds an extra piece of information to the
alg_exp_node struct, duplicated from the control connection, that
identifies the Alg under use. It then makes use of that in
expectation_lookup, to check if the given src address should be
whitelisted or not, before proceeding with the comparison with each
expectation in the list of expectations.

Signed-off-by: Tiago Lam 
---
 lib/conntrack-private.h |  3 ++-
 lib/conntrack.c | 32 +++-
 2 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/lib/conntrack-private.h b/lib/conntrack-private.h
index a344801d8..bf1d0773b 100644
--- a/lib/conntrack-private.h
+++ b/lib/conntrack-private.h
@@ -79,9 +79,10 @@ struct alg_exp_node {
 /* The NAT replacement address to be used by the data connection. */
 struct ct_addr alg_nat_repl_addr;
 /* The data connection inherits the master control
- * connection label and mark. */
+ * connection label, mark and alg. */
 ovs_u128 master_label;
 uint32_t master_mark;
+char *master_alg;
 /* True if for NAT application, the alg replaces the dest address;
  * otherwise, the source address is replaced.  */
 bool nat_rpl_dst;
diff --git a/lib/conntrack.c b/lib/conntrack.c
index a3cff1575..5c91f374b 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -131,8 +131,7 @@ extract_l3_ipv6(struct conn_key *key, const void *data, 
size_t size,
 const char **new_data);
 
 static struct alg_exp_node *
-expectation_lookup(struct hmap *alg_expectations, const struct conn_key *key,
-   uint32_t basis, bool src_ip_wc);
+expectation_lookup(struct hmap *alg_expectations, const struct conn_key *key);
 
 static int
 repl_ftp_v4_addr(struct dp_packet *pkt, ovs_be32 v4_addr_rep,
@@ -505,9 +504,9 @@ get_alg_ctl_type(const struct dp_packet *pkt, ovs_be16 
tp_src, ovs_be16 tp_dst,
 }
 
 static bool
-alg_src_ip_wc(enum ct_alg_ctl_type alg_ctl_type)
+alg_src_ip_wc(const char *alg)
 {
-if (alg_ctl_type == CT_ALG_CTL_SIP) {
+if (!strncmp(alg, "sip", strlen("sip"))) {
 return true;
 }
 return false;
@@ -1252,9 +1251,7 @@ process_one(struct conntrack *ct, struct dp_packet *pkt,
 struct alg_exp_node alg_exp_entry;
 
 ct_rwlock_rdlock(>resources_lock);
-alg_exp = expectation_lookup(>alg_expectations, >key,
- ct->hash_basis,
- alg_src_ip_wc(ct_alg_ctl));
+alg_exp = expectation_lookup(>alg_expectations, >key);
 if (alg_exp) {
 alg_exp_entry = *alg_exp;
 alg_exp = _exp_entry;
@@ -2539,21 +2536,21 @@ conntrack_get_nconns(struct conntrack *ct, uint32_t 
*nconns)
 
 /* This function must be called with the ct->resources read lock taken. */
 static struct alg_exp_node *
-expectation_lookup(struct hmap *alg_expectations, const struct conn_key *key,
-   uint32_t basis, bool src_ip_wc)
+expectation_lookup(struct hmap *alg_expectations, const struct conn_key *key)
 {
 struct conn_key check_key = *key;
 check_key.src.port = ALG_WC_SRC_PORT;
 
-if (src_ip_wc) {
-memset(_key.src.addr, 0, sizeof check_key.src.addr);
-}
-
 struct alg_exp_node *alg_exp_node;
+struct alg_exp_node *next;
+
+HMAP_FOR_EACH_SAFE (alg_exp_node, next, node, alg_expectations) {
+bool is_wc = alg_src_ip_wc(alg_exp_node->master_alg);
+
+if (is_wc) {
+memset(_key.src.addr, 0, sizeof check_key.src.addr);
+}
 
-HMAP_FOR_EACH_WITH_HASH (alg_exp_node, node,
- conn_key_hash(_key, basis),
- alg_expectations) {
 if (!conn_key_cmp(_exp_node->key, _key)) {
 return alg_exp_node;
 }
@@ -2666,12 +2663,13 @@ expectation_create_outband(struct conntrack *ct, struct 
ct_addr src_addr,
 alg_exp_node->master_mark = master_conn->mark;
 alg_exp_node->master_label = master_conn->label;
 alg_exp_node->master_key = master_conn->key;
+alg_exp_node->master_alg = nullable_xstrdup(master_conn->alg);
 /* Take the write lock here because it is almost 100%
  * likely that the lookup will fail and
  * expectation_create() will be called below. */
 ct_rwlock_wrlock(>resources_lock);
 struct alg_exp_node *alg_exp = expectation_lookup(
->alg_expectations, _exp_node->key, ct->hash_basis, src_ip_wc);
+>alg_expectations, _exp_node->key);
 if (alg_exp) {
 free(alg_exp_node);
 ct_rwlock_unlock(>resources_lock);
-- 
2.14.3

___
dev mailing list

[ovs-dev] [RFC PATCH v2 2/6] Conntrack: Support "out-of-band" expectations.

[Tiago Lam]

A new function, expectation_create_outband, is introduced to allow more
flexibility when creating the expectations (e.g. specify the network
protocol for the expectation, or a different destination address from
where the initial request came from).

Signed-off-by: Tiago Lam 
---
 lib/conntrack.c | 49 -
 1 file changed, 32 insertions(+), 17 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index fe5fd0fe8..a3cff1575 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2631,41 +2631,33 @@ expectation_clean(struct conntrack *ct, const struct 
conn_key *master_key,
 ct_rwlock_unlock(>resources_lock);
 }
 
-static void
-expectation_create(struct conntrack *ct, ovs_be16 dst_port,
-   const struct conn *master_conn, bool reply, bool src_ip_wc,
-   bool skip_nat)
+void
+expectation_create_outband(struct conntrack *ct, struct ct_addr src_addr,
+   struct ct_addr dst_addr, ovs_be16 dst_port,
+   const struct conn *master_conn, bool reply,
+   bool src_ip_wc, bool skip_nat, uint8_t nw_proto)
 {
-struct ct_addr src_addr;
-struct ct_addr dst_addr;
-struct ct_addr alg_nat_repl_addr;
 struct alg_exp_node *alg_exp_node = xzalloc(sizeof *alg_exp_node);
+struct ct_addr alg_nat_repl_addr;
 
 if (reply) {
-src_addr = master_conn->key.src.addr;
-dst_addr = master_conn->key.dst.addr;
+alg_exp_node->nat_rpl_dst = true;
 if (skip_nat) {
 alg_nat_repl_addr = dst_addr;
 } else {
 alg_nat_repl_addr = master_conn->rev_key.dst.addr;
 }
-alg_exp_node->nat_rpl_dst = true;
 } else {
-src_addr = master_conn->rev_key.src.addr;
-dst_addr = master_conn->rev_key.dst.addr;
+alg_exp_node->nat_rpl_dst = false;
 if (skip_nat) {
 alg_nat_repl_addr = src_addr;
 } else {
 alg_nat_repl_addr = master_conn->key.src.addr;
 }
-alg_exp_node->nat_rpl_dst = false;
-}
-if (src_ip_wc) {
-memset(_addr, 0, sizeof src_addr);
 }
 
 alg_exp_node->key.dl_type = master_conn->key.dl_type;
-alg_exp_node->key.nw_proto = master_conn->key.nw_proto;
+alg_exp_node->key.nw_proto = nw_proto;
 alg_exp_node->key.zone = master_conn->key.zone;
 alg_exp_node->key.src.addr = src_addr;
 alg_exp_node->key.dst.addr = dst_addr;
@@ -2694,6 +2686,29 @@ expectation_create(struct conntrack *ct, ovs_be16 
dst_port,
 ct_rwlock_unlock(>resources_lock);
 }
 
+static void
+expectation_create(struct conntrack *ct, ovs_be16 dst_port,
+   const struct conn *master_conn, bool reply,
+   bool src_ip_wc, bool skip_nat) {
+struct ct_addr src_addr;
+struct ct_addr dst_addr;
+
+if (reply) {
+src_addr = master_conn->key.src.addr;
+dst_addr = master_conn->key.dst.addr;
+} else {
+src_addr = master_conn->rev_key.src.addr;
+dst_addr = master_conn->rev_key.dst.addr;
+}
+if (src_ip_wc) {
+memset(_addr, 0, sizeof src_addr);
+}
+
+expectation_create_outband(ct, src_addr, dst_addr, dst_port, master_conn,
+   reply, src_ip_wc, skip_nat,
+   master_conn->key.nw_proto);
+}
+
 static uint8_t
 get_v4_byte_be(ovs_be32 v4_addr, uint8_t index)
 {
-- 
2.14.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC PATCH v2 0/6] Initial support for new SIP Alg.

[Tiago Lam]

v1 -> v2:
- Addressed comments from v1 (from both Darrell and Mark, thanks!);
- Added support for UDP;
- Added tests for each supported transport, UDP and TCP, and some more
  individual tests for testing particular functions (around parsing and
  framing).

A couple of points worth mentioning in v2:
- Support for TCP framing, in patch 4/6, is not yet optimal as it
  dismisses SIP messages that span across multiple TCP packets. I plan
  to focus on that next;
- Patches 2/6 and 3/6 are independent (can be applied separately of this
  patchset) and provide some flexibility for protocols such as SIP. More
  details in each separate patch.

Regards,

Tiago

Tiago Lam (6):
  Conntrack: Add new API for future SIP Alg.
  Conntrack: Support "out-of-band" expectations.
  Conntrack: Add alg to alg_exp_node struct.
  Conntrack: Add initial support for new SIP Alg.
  Conntrack: Add SIP end-to-end and unit tests.
  Conntrack: Add UDP support for SIP.

 include/openvswitch/ofp-actions.h  |   4 +
 lib/automake.mk|   2 +
 lib/conntrack-private.h|  33 +-
 lib/conntrack-sip.c| 959 +
 lib/conntrack-sip.h| 176 ++
 lib/conntrack.c| 133 +++--
 lib/ofp-parse.c|   5 +
 ofproto/ofproto-dpif-xlate.c   |   3 +
 tests/atlocal.in   |   3 +
 tests/automake.mk  |   8 +
 tests/conntrack-sip.at |   7 +
 tests/sipp/uac_happy_case_scenario.xml | 126 +
 tests/sipp/uas_happy_case_scenario.xml | 125 +
 tests/system-traffic.at| 142 +
 tests/test-sip.c   | 485 +
 tests/testsuite.at |   1 +
 16 files changed, 2157 insertions(+), 55 deletions(-)
 create mode 100644 lib/conntrack-sip.c
 create mode 100644 lib/conntrack-sip.h
 create mode 100644 tests/conntrack-sip.at
 create mode 100644 tests/sipp/uac_happy_case_scenario.xml
 create mode 100644 tests/sipp/uas_happy_case_scenario.xml
 create mode 100644 tests/test-sip.c

-- 
2.14.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] conntrack: Support conntrack flush by ct 5-tuple

[Yi-Hung Wei]

This patch adds support of flushing a conntrack entry specified by the
conntrack 5-tuple in dpif-netdev.

Signed-off-by: Yi-Hung Wei 
---
Respin this patch since userspace conntrack now clears out the expectation
when a conntrack entry is deleted.
---
 lib/conntrack.c  | 72 
 lib/conntrack.h  |  3 ++
 lib/dpif-netdev.c|  2 +-
 tests/system-kmod-macros.at  |  8 -
 tests/system-traffic.at  |  1 -
 tests/system-userspace-macros.at | 10 --
 6 files changed, 76 insertions(+), 20 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index fe5fd0fe8be1..c05b3901d7af 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2368,6 +2368,10 @@ delete_conn(struct conn *conn)
 free(conn);
 }
 
+/* Convert a conntrack address 'a' into an IP address 'b' based on 'dl_type'.
+ *
+ * Note that 'dl_type' should be either "ETH_TYPE_IP" or "ETH_TYPE_IPv6"
+ * in network-byte order. */
 static void
 ct_endpoint_to_ct_dpif_inet_addr(const struct ct_addr *a,
  union ct_dpif_inet_addr *b,
@@ -2380,6 +2384,22 @@ ct_endpoint_to_ct_dpif_inet_addr(const struct ct_addr *a,
 }
 }
 
+/* Convert an IP address 'a' into a conntrack address 'b' based on 'dl_type'.
+ *
+ * Note that 'dl_type' should be either "ETH_TYPE_IP" or "ETH_TYPE_IPv6"
+ * in network-byte order. */
+static void
+ct_dpif_inet_addr_to_ct_endpoint(const union ct_dpif_inet_addr *a,
+ struct ct_addr *b,
+ ovs_be16 dl_type)
+{
+if (dl_type == htons(ETH_TYPE_IP)) {
+b->ipv4_aligned = a->ip;
+} else if (dl_type == htons(ETH_TYPE_IPV6)){
+b->ipv6_aligned = a->in6;
+}
+}
+
 static void
 conn_key_to_tuple(const struct conn_key *key, struct ct_dpif_tuple *tuple)
 {
@@ -2405,6 +2425,35 @@ conn_key_to_tuple(const struct conn_key *key, struct 
ct_dpif_tuple *tuple)
 }
 
 static void
+tuple_to_conn_key(const struct ct_dpif_tuple *tuple, uint16_t zone,
+  struct conn_key *key)
+{
+if (tuple->l3_type == AF_INET) {
+key->dl_type = htons(ETH_TYPE_IP);
+} else if (tuple->l3_type == AF_INET6) {
+key->dl_type = htons(ETH_TYPE_IPV6);
+}
+key->nw_proto = tuple->ip_proto;
+ct_dpif_inet_addr_to_ct_endpoint(>src, >src.addr,
+ key->dl_type);
+ct_dpif_inet_addr_to_ct_endpoint(>dst, >dst.addr,
+ key->dl_type);
+
+if (tuple->ip_proto == IPPROTO_ICMP || tuple->ip_proto == IPPROTO_ICMPV6) {
+key->src.icmp_id = tuple->icmp_id;
+key->src.icmp_type = tuple->icmp_type;
+key->src.icmp_code = tuple->icmp_code;
+key->dst.icmp_id = tuple->icmp_id;
+key->dst.icmp_type = reverse_icmp_type(tuple->icmp_type);
+key->dst.icmp_code = tuple->icmp_code;
+} else {
+key->src.port = tuple->src_port;
+key->dst.port = tuple->dst_port;
+}
+key->zone = zone;
+}
+
+static void
 conn_to_ct_dpif_entry(const struct conn *conn, struct ct_dpif_entry *entry,
   long long now, int bkt)
 {
@@ -2517,6 +2566,29 @@ conntrack_flush(struct conntrack *ct, const uint16_t 
*zone)
 }
 
 int
+conntrack_flush_tuple(struct conntrack *ct, const struct ct_dpif_tuple *tuple,
+  uint16_t zone)
+{
+struct conn_lookup_ctx ctx;
+int error = 0;
+
+memset(, 0, sizeof(ctx));
+tuple_to_conn_key(tuple, zone, );
+ctx.hash = conn_key_hash(, ct->hash_basis);
+unsigned bucket = hash_to_bucket(ctx.hash);
+
+ct_lock_lock(>buckets[bucket].lock);
+conn_key_lookup(>buckets[bucket], , time_msec());
+if (ctx.conn) {
+conn_clean(ct, ctx.conn, >buckets[bucket]);
+} else {
+error = ENOENT;
+}
+ct_lock_unlock(>buckets[bucket].lock);
+return error;
+}
+
+int
 conntrack_set_maxconns(struct conntrack *ct, uint32_t maxconns)
 {
 atomic_store_relaxed(>n_conn_limit, maxconns);
diff --git a/lib/conntrack.h b/lib/conntrack.h
index ac650304a41f..e3a5dcc8023f 100644
--- a/lib/conntrack.h
+++ b/lib/conntrack.h
@@ -109,6 +109,7 @@ struct conntrack_dump {
 };
 
 struct ct_dpif_entry;
+struct ct_dpif_tuple;
 
 int conntrack_dump_start(struct conntrack *, struct conntrack_dump *,
  const uint16_t *pzone, int *);
@@ -116,6 +117,8 @@ int conntrack_dump_next(struct conntrack_dump *, struct 
ct_dpif_entry *);
 int conntrack_dump_done(struct conntrack_dump *);
 
 int conntrack_flush(struct conntrack *, const uint16_t *zone);
+int conntrack_flush_tuple(struct conntrack *, const struct ct_dpif_tuple *,
+  uint16_t zone);
 int conntrack_set_maxconns(struct conntrack *ct, uint32_t maxconns);
 int conntrack_get_maxconns(struct conntrack *ct, uint32_t *maxconns);
 int conntrack_get_nconns(struct conntrack *ct, uint32_t *nconns);
diff --git a/lib/dpif-netdev.c 

[ovs-dev] [PATCH] Refer to database manpages in *ctl manpages

[Mark Michelson]

The ovn-nbctl, ovn-sbctl, and ovs-vsctl manpages are inconsistent in
their "Database Commands" section when it comes to referring to what
database tables exist. This commit amends this by making each *ctl
manpage reference the corresponding database manpage instead.

Signed-off-by: Mark Michelson 
---
While having a look through the manpages for ovn-nbctl, ovn-sbctl, and
ovs-vsctl, I noticed that each of them were different with regards to
referring to tables:

* ovn-nbctl listed tables but the list was incomplete.
* ovn-sbctl listed no tables at all.
* ovs-vsctl listed all tables.

To me, there were two ways to go here: list all tables in each of the
three manpages, or list no tables in the three manpages. In the end, I
decided to make a reference to the database manpages. This way we're not
repeating table listings and there's no risk of omitting tables. The
database manpages are better references anyway for tables and their
columns.
---
 ovn/utilities/ovn-nbctl.8.xml | 60 +++
 ovn/utilities/ovn-sbctl.8.in  |  4 +--
 utilities/ovs-vsctl.8.in  | 50 +---
 3 files changed, 6 insertions(+), 108 deletions(-)

diff --git a/ovn/utilities/ovn-nbctl.8.xml b/ovn/utilities/ovn-nbctl.8.xml
index 4d0aea963..5a8f5dacf 100644
--- a/ovn/utilities/ovn-nbctl.8.xml
+++ b/ovn/utilities/ovn-nbctl.8.xml
@@ -820,64 +820,10 @@
 additional ways to identify records.  Some commands also take
 column parameters that identify a particular field within the
 records in a table.
-The following tables are currently defined:
-
-  Logical_Switch
-  
-An L2 logical switch.  Records may be identified by name.
-  
-
-  Logical_Switch_Port
-  
-A port within an L2 logical switch.  Records may be identified by name.
-  
-
-  ACL
-  
-An ACL rule for a logical switch that points to it through its 
acls column.
-  
-
-  Logical_Router
-  
-An L3 logical router.  Records may be identified by name.
-  
-
-  Logical_Router_Port
-  
-A port within an L3 logical router.  Records may be identified by name.
-  
-
-  Logical_Router_Static_Route
-  
-A static route belonging to an L3 logical router.
-  
 
-  Address_Set
-  
-An address set that can be used in ACLs.
-  
-
-  Load_Balancer
-  
-A load balancer for a logical switch that points to it through its 
load_balancer column.
-  
-
-  NAT
-  
-A NAT rule for a Gateway router.
-  
-
-  DHCP_Options
-  
-DHCP options.
-  
-
-  NB_Global
-  
-North bound global configurations.
-  
-
-
+
+  For a list of tables and their columns, see ovn-nb(5).
+
 
 
   Record names must be specified in full and with correct capitalization,
diff --git a/ovn/utilities/ovn-sbctl.8.in b/ovn/utilities/ovn-sbctl.8.in
index cd43cf3be..40807c1dc 100644
--- a/ovn/utilities/ovn-sbctl.8.in
+++ b/ovn/utilities/ovn-sbctl.8.in
@@ -278,8 +278,8 @@ parameter may be the UUID for a record, and many tables 
offer
 additional ways to identify records.  Some commands also take
 \fIcolumn\fR parameters that identify a particular field within the
 records in a table.
-.\" It would be kind to list all the tables and their supported identifiers
-.\" here.
+.PP
+For a list of tables and their columns, see \fBovn\-sb\fR(5).
 .PP
 Record names must be specified in full and with correct
 capitalization, except that UUIDs may be abbreviated to their first 4
diff --git a/utilities/ovs-vsctl.8.in b/utilities/ovs-vsctl.8.in
index 34f41e4e8..374dd5368 100644
--- a/utilities/ovs-vsctl.8.in
+++ b/utilities/ovs-vsctl.8.in
@@ -530,55 +530,7 @@ additional ways to identify records.  Some commands also 
take
 \fIcolumn\fR parameters that identify a particular field within the
 records in a table.
 .PP
-The following tables are currently defined:
-.IP "\fBOpen_vSwitch\fR"
-Global configuration for an \fBovs\-vswitchd\fR.  This table contains
-exactly one record, identified by specifying \fB.\fR as the record
-name.
-.IP "\fBBridge\fR"
-Configuration for a bridge within an Open vSwitch.  Records may be
-identified by bridge name.
-.IP "\fBPort\fR"
-A bridge port.  Records may be identified by port name.
-.IP "\fBInterface\fR"
-A network device attached to a port.  Records may be identified by
-name.
-.IP "\fBFlow_Table\fR"
-Configuration for a particular OpenFlow flow table.  Records may be
-identified by name.
-.IP "\fBQoS\fR"
-Quality-of-service configuration for a \fBPort\fR.  Records may be
-identified by port name.
-.IP "\fBQueue\fR"
-Configuration for one queue within a \fBQoS\fR configuration.  Records
-may only be identified by UUID.
-.IP "\fBMirror\fR"
-A port mirroring configuration attached to a bridge.  Records may be
-identified by mirror name.
-.IP "\fBController\fR"
-Configuration for an 

Re: [ovs-dev] [PATCH v3 2/2] Measure performance of ovn-controller loop.

[Mark Michelson]

On 02/12/2018 12:58 PM, Han Zhou wrote:



On Mon, Feb 12, 2018 at 6:16 AM, Mark Michelson > wrote:

 >
 > On 02/09/2018 07:36 PM, Han Zhou wrote:
 >>
 >> Looks a great tool! Just some minor comments:
 >>
 >> On Fri, Feb 9, 2018 at 3:00 PM, Mark Michelson  >> wrote:

 >>  >
 >>  > This modifies ovn-controller to measure the amount of time it 
takes to
 >>  > detect a change in the southbound database, generate the 
resulting flow

 >>  > table, and write the flow table down to vswitchd.
 >>
 >> The comment is a little inaccurate. The change cannot guarantee 
measurement of "write the flow table down to vswitchd", since sending 
the flow-adding messages to vswitchd could be performed in multiple 
iterations of the main loop, depending on the buffering status of 
vconn_send(). If it can't be completed in one round, the message 
sendings will continue in next loops in ofctrl_run().

 >
 >
 > Thanks for the review Han. I attempted to account for this in the 
code by only ending the sample in the case that ofctrl_can_put() returns 
true. This way, we might start a measurement in one loop iteration, but 
the measurement might not end until a later iteration if 
ofctrl_can_put() returns false. Do you have suggestions for other 
factors that I should take into account for determining when to end a 
measurement?

 >

I think one way to address this, if we really want to, is to compare 
ofctrl_get_cur_cfg() with get_nb_cfg(ctx.ovnsb_idl). If they are equal, 
it means ovs-vswitchd caught up with SB with all required flows installed.
I suggest to have separate measurements, one for main loop execution 
time, one for SB change handling up until flows installed to OVS. They 
could be separate patches. What do you think?




That sounds like a good approach. Thanks for the feedback!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCHv2] poc: Introduce Proof of Concepts (Package building)

[Ansis Atteka]

On 12 February 2018 at 10:41, Gregory Rose  wrote:
> On 2/4/2018 6:48 PM, Ansis Atteka wrote:
>>
>> From: Ansis Atteka 
>>
>> This patch sets up foundations for Proof of Concepts that
>> simply materialize documentation into Ansible instructions
>> executed in virtualized Vagrant environment.
>>
>> This Proof of Concept allows to easily build:
>> 1. *.deb packages on Ubuntu 16.04; AND
>> 2. *.rpm packages on CentOS 7.4.
>> It also sets up DEB and RPM repository over HTTP that can
>> be used to pull these openvswitch packages with apt-get
>> or yum from another host.
>>
>> This particular Proof of Concept is intended to address
>> following use-cases:
>> 1. for new OVS users to see how debian and rpm packages are
>> built;
>> 2. for developers to easily check for packaging build
>> regressions;
>> 3. for developers to easily share their sandbox builds
>> into QE setups (opposed to manually copying binaries);
>> 4. for developers to add other Proof of Concepts
>> that possibly may require full end-to-end integration
>> with other thirdparty projects (e.g. DPI, libvirt, IPsec)
>> and need Open vSwitch packages.
>>
>> Tested-by: Greg Rose 
>> Reviewed-by: Greg Rose 
>> Signed-off-by: Ansis Atteka 
>
>
> Rev 2 looks good.  I did a quick sanity check test and LGTM.
>
> Reviewed-by: Greg Rose 

Thanks, I pushed this to master.
>
>
>> ---
>>   .gitignore   |   2 +
>>   Documentation/topics/testing.rst |  56 
>>   Makefile.am  |   3 ++
>>   poc/builders/Vagrantfile |  33 
>>   poc/playbook-centos-builder.yml  | 108
>> +++
>>   poc/playbook-ubuntu-builder.yml  |  70 +
>>   6 files changed, 272 insertions(+)
>>   create mode 100644 poc/builders/Vagrantfile
>>   create mode 100644 poc/playbook-centos-builder.yml
>>   create mode 100644 poc/playbook-ubuntu-builder.yml
>>
>> diff --git a/.gitignore b/.gitignore
>> index 8019bee41..81faf270d 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -16,6 +16,7 @@
>>   *.lib
>>   *.pdb
>>   *.pyc
>> +*.retry
>>   *.so
>>   *.suo
>>   **/*.sym
>> @@ -29,6 +30,7 @@
>>   .dirstamp
>>   .libs
>>   .tmp_versions
>> +.vagrant
>>   .gitattributes
>>   /Makefile
>>   /Makefile.in
>> diff --git a/Documentation/topics/testing.rst
>> b/Documentation/topics/testing.rst
>> index a49336b79..253857171 100644
>> --- a/Documentation/topics/testing.rst
>> +++ b/Documentation/topics/testing.rst
>> @@ -389,3 +389,59 @@ validate the suitability of different vSwitch
>> implementations in a telco
>>   deployment environment. More information can be found on the `OPNFV
>> wiki`_.
>> .. _OPNFV wiki: https://wiki.opnfv.org/display/vsperf/VSperf+Home
>> +
>> +Proof of Concepts
>> +~
>> +
>> +Proof of Concepts are documentation materialized into Ansible recipes
>> +executed in VirtualBox or Libvirt environments orchastrated by Vagrant.
>> +Proof of Concepts allow developers to create small virtualized setups
>> that
>> +demonstrate how certain Open vSwitch features are intended to work
>> avoiding
>> +user introduced errors by overlooking instructions.  Proof of Concepts
>> +are also helpful when integrating with thirdparty software, because
>> standard
>> +unit tests with make check are limited.
>> +
>> +Vagrant by default uses VirtualBox provider.  However, if Libvirt is your
>> +choice of virtualization technology, then you can use it by installing
>> Libvirt
>> +plugin:
>> +
>> +$ vagrant plugin install vagrant-libvirt
>> +
>> +And then appending  --provider=libvirt flag to vagrant commands.
>> +
>> +The host where Vagrant runs does not need to have any special software
>> +installed besides vagrant, virtualbox (or libvirt and libvirt-dev) and
>> +ansible.
>> +
>> +The following Proof of Concepts are supported:
>> +
>> +Builders
>> +
>> +
>> +This particular Proof of Concept demonsrtates integration with Debian and
>> RPM
>> +packaging tools:
>> +
>> +$ cd ./poc/builders
>> +
>> +$ vagrant up
>> +
>> +Once that command finished you can get packages from /var/www/html
>> +directory.  Since those hosts are also configured as repositories then
>> +you can add them to /etc/apt/sources.list.d or /etc/yum.repos.d
>> +configuration files on another host to retrieve packages with yum or
>> +apt-get.
>> +
>> +hen you have made changes to OVS source code and want to rebuild packages
>> run:
>> +$ git commit -a
>> +$ vagrant rsync && vagrant provision
>> +
>> +Whenever packages are rebuilt the Open vSwitch release number increases
>> +by one and you can simply upgrade Open vSwitch by running yum or apt-get
>> +update commands.
>> +
>> +Once you are done with experimenting you can tear down setup with:
>> +
>> +$ vagrant destroy
>> +
>> +Sometimes deployment of Proof of 

Re: [ovs-dev] [PATCH v3 2/2] Measure performance of ovn-controller loop.

[Han Zhou]

On Mon, Feb 12, 2018 at 6:16 AM, Mark Michelson  wrote:
>
> On 02/09/2018 07:36 PM, Han Zhou wrote:
>>
>> Looks a great tool! Just some minor comments:
>>
>> On Fri, Feb 9, 2018 at 3:00 PM, Mark Michelson > wrote:
>>  >
>>  > This modifies ovn-controller to measure the amount of time it takes to
>>  > detect a change in the southbound database, generate the resulting
flow
>>  > table, and write the flow table down to vswitchd.
>>
>> The comment is a little inaccurate. The change cannot guarantee
measurement of "write the flow table down to vswitchd", since sending the
flow-adding messages to vswitchd could be performed in multiple iterations
of the main loop, depending on the buffering status of vconn_send(). If it
can't be completed in one round, the message sendings will continue in next
loops in ofctrl_run().
>
>
> Thanks for the review Han. I attempted to account for this in the code by
only ending the sample in the case that ofctrl_can_put() returns true. This
way, we might start a measurement in one loop iteration, but the
measurement might not end until a later iteration if ofctrl_can_put()
returns false. Do you have suggestions for other factors that I should take
into account for determining when to end a measurement?
>

I think one way to address this, if we really want to, is to compare
ofctrl_get_cur_cfg() with get_nb_cfg(ctx.ovnsb_idl). If they are equal, it
means ovs-vswitchd caught up with SB with all required flows installed.
I suggest to have separate measurements, one for main loop execution time,
one for SB change handling up until flows installed to OVS. They could be
separate patches. What do you think?

>
>>
>>  >
>>  > The statistics can be queried using:
>>  >
>>  > ovs-appctl -t ovn-controller performance/show ovn-controller-loop
>>  >
>>  > Signed-off-by: Mark Michelson 
>>
>>  > ---
>>  >  ovn/controller/ovn-controller.c | 17 +
>>  >  1 file changed, 17 insertions(+)
>>  >
>>  > diff --git a/ovn/controller/ovn-controller.c
b/ovn/controller/ovn-controller.c
>>  > index 7592bda25..b9f8950d4 100644
>>  > --- a/ovn/controller/ovn-controller.c
>>  > +++ b/ovn/controller/ovn-controller.c
>>  > @@ -57,6 +57,9 @@
>>  >  #include "stream.h"
>>  >  #include "unixctl.h"
>>  >  #include "util.h"
>>  > +#include "timeval.h"
>>  > +#include "timer.h"
>>  > +#include "performance.h"
>>  >
>>  >  VLOG_DEFINE_THIS_MODULE(main);
>>  >
>>  > @@ -67,6 +70,8 @@ static unixctl_cb_func inject_pkt;
>>  >  #define DEFAULT_BRIDGE_NAME "br-int"
>>  >  #define DEFAULT_PROBE_INTERVAL_MSEC 5000
>>  >
>>  > +#define CONTROLLER_LOOP_PERFORMANCE_NAME "ovn-controller-loop"
>>  > +
>>  >  static void update_probe_interval(struct controller_ctx *,
>>  >const char *ovnsb_remote);
>>  >  static void parse_options(int argc, char *argv[]);
>>  > @@ -639,8 +644,10 @@ main(int argc, char *argv[])
>>  >  unixctl_command_register("inject-pkt", "MICROFLOW", 1, 1,
inject_pkt,
>>  >   _pkt);
>>  >
>>  > +performance_create(CONTROLLER_LOOP_PERFORMANCE_NAME, PERF_MS);
>>  >  /* Main loop. */
>>  >  exiting = false;
>>  > +unsigned int our_seqno = 0;
>>  >  while (!exiting) {
>>  >  /* Check OVN SB database. */
>>  >  char *new_ovnsb_remote = get_ovnsb_remote(ovs_idl_loop.idl);
>>  > @@ -659,6 +666,12 @@ main(int argc, char *argv[])
>>  >  .ovnsb_idl_txn = ovsdb_idl_loop_run(_idl_loop),
>>  >  };
>>  >
>>  > +if (our_seqno != ovsdb_idl_get_seqno(ctx.ovnsb_idl)) {
>>
>> Shall we measure when there is no SB change, too? E.g. the loop can be
triggered by local ovs-idl change, or by pin-ctrl messages, and these
changes will trigger all the flow computations, which contributes a
significant cost in ovn-controller, so I think we'd better measure them as
well. I am working on an incremental processing framework which would avoid
this kind of unnecessary recompute. I hope with this tool the improvements
can be measured accurately :)
>>
>>  > +
 performance_start_sample(CONTROLLER_LOOP_PERFORMANCE_NAME,
>>  > + time_msec());
>>  > +our_seqno = ovsdb_idl_get_seqno(ctx.ovnsb_idl);
>>  > +}
>>  > +
>>  >  update_probe_interval(, ovnsb_remote);
>>  >
>>  >  update_ssl_config(ctx.ovs_idl);
>>  > @@ -728,6 +741,9 @@ main(int argc, char *argv[])
>>  >  ofctrl_put(_table, _ct_zones,
>>  > get_nb_cfg(ctx.ovnsb_idl));
>>  >
>>  > +
performance_end_sample(CONTROLLER_LOOP_PERFORMANCE_NAME,
>>  > +   time_msec());
>>  > +
>>  >  hmap_destroy(_table);
>>  >  }
>>  >  if (ctx.ovnsb_idl_txn) {
>>  > @@ -792,6 +808,7 @@ main(int argc, char *argv[])
>>  >  ofctrl_wait();
>>  >  

[ovs-dev] [PATCH 7/8] doc: Split Jumbo Frames guide between two docs

[Stephen Finucane]

While there is some duplication going on here, that's not necessarily a
bad thing. If nothing else, it lets us remove one more overly-detailed
step from the howto.

Signed-off-by: Stephen Finucane 
---
 Documentation/howto/dpdk.rst | 52 ++--
 Documentation/topics/dpdk/phy.rst| 24 +++
 Documentation/topics/dpdk/vhost-user.rst | 36 ++
 3 files changed, 63 insertions(+), 49 deletions(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index 1a72e90bf..ba01810f8 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -48,9 +48,9 @@ number of dpdk devices found in the log file::
 $ ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk \
 options:dpdk-devargs=:01:00.1
 
-Some NICs (i.e. Mellanox ConnectX-3) have only one PCI address associated
-with multiple ports. Using a PCI device like above won't work. Instead, below
-usage is suggested::
+Some NICs (i.e. Mellanox ConnectX-3) have only one PCI address associated with
+multiple ports. Using a PCI device like above won't work. Instead, below usage
+is suggested::
 
 $ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
 options:dpdk-devargs="class=eth,mac=00:11:22:33:44:55:01"
@@ -85,52 +85,6 @@ To stop ovs-vswitchd & delete bridge, run::
 $ ovs-appctl -t ovsdb-server exit
 $ ovs-vsctl del-br br0
 
-Jumbo Frames
-
-
-By default, DPDK ports are configured with standard Ethernet MTU (1500B). To
-enable Jumbo Frames support for a DPDK port, change the Interface's
-``mtu_request`` attribute to a sufficiently large value. For example, to add a
-DPDK Phy port with MTU of 9000::
-
-$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
-  options:dpdk-devargs=:01:00.0 mtu_request=9000
-
-Similarly, to change the MTU of an existing port to 6200::
-
-$ ovs-vsctl set Interface dpdk-p0 mtu_request=6200
-
-Some additional configuration is needed to take advantage of jumbo frames with
-vHost ports:
-
-1. *mergeable buffers* must be enabled for vHost ports, as demonstrated in the
-   QEMU command line snippet below::
-
-   -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
-   -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=on
-
-2. Where virtio devices are bound to the Linux kernel driver in a guest
-   environment (i.e. interfaces are not bound to an in-guest DPDK driver), the
-   MTU of those logical network interfaces must also be increased to a
-   sufficiently large value. This avoids segmentation of Jumbo Frames received
-   in the guest. Note that 'MTU' refers to the length of the IP packet only,
-   and not that of the entire frame.
-
-   To calculate the exact MTU of a standard IPv4 frame, subtract the L2 header
-   and CRC lengths (i.e. 18B) from the max supported frame size.  So, to set
-   the MTU for a 9018B Jumbo Frame::
-
-   $ ip link set eth1 mtu 9000
-
-When Jumbo Frames are enabled, the size of a DPDK port's mbuf segments are
-increased, such that a full Jumbo Frame of a specific size may be accommodated
-within a single mbuf segment.
-
-Jumbo frame support has been validated against 9728B frames, which is the
-largest frame size supported by Fortville NIC using the DPDK i40e driver, but
-larger frames and other DPDK NIC drivers may be supported. These cases are
-common for use cases involving East-West traffic only.
-
 .. _dpdk-ovs-in-guest:
 
 OVS with DPDK Inside VMs
diff --git a/Documentation/topics/dpdk/phy.rst 
b/Documentation/topics/dpdk/phy.rst
index 93aff628c..d49269567 100644
--- a/Documentation/topics/dpdk/phy.rst
+++ b/Documentation/topics/dpdk/phy.rst
@@ -216,3 +216,27 @@ Flow Control
 
 Flow control is available for DPDK physical ports. For more information, refer
 to :ref:`dpdk-flow-control`.
+
+Jumbo Frames
+
+
+By default, ``dpdk`` ports are configured with standard Ethernet MTU (1500B).
+To enable Jumbo Frames support for such a port, change the interface's
+``mtu_request`` attribute to a sufficiently large value. For example, to add a
+``dpdk`` port with MTU of 9000, run::
+
+$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
+options:dpdk-devargs=:01:00.0 mtu_request=9000
+
+Similarly, to change the MTU of an existing port to 6200::
+
+$ ovs-vsctl set Interface dpdk-p0 mtu_request=6200
+
+When Jumbo Frames are enabled, the size of a DPDK port's mbuf segments are
+increased, such that a full Jumbo Frame of a specific size may be accommodated
+within a single mbuf segment.
+
+Jumbo frame support has been validated against 9728B frames, which is the
+largest frame size supported by Fortville NIC using the DPDK i40e driver, but
+larger frames and other DPDK NIC drivers may be supported. These cases are
+common for use cases involving East-West traffic only.
diff --git 

[ovs-dev] [PATCH 5/8] doc: Add "bridge" topic document

[Stephen Finucane]

This details configuration steps that apply to the entire bridge, rather
than individual ports.

Signed-off-by: Stephen Finucane 
---
 Documentation/howto/dpdk.rst |  60 
 Documentation/topics/dpdk/bridge.rst | 103 +++
 Documentation/topics/dpdk/index.rst  |   1 +
 3 files changed, 104 insertions(+), 60 deletions(-)
 create mode 100644 Documentation/topics/dpdk/bridge.rst

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index 608dde814..c01bf7a39 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -170,66 +170,6 @@ largest frame size supported by Fortville NIC using the 
DPDK i40e driver, but
 larger frames and other DPDK NIC drivers may be supported. These cases are
 common for use cases involving East-West traffic only.
 
-.. _extended-statistics:
-
-Extended & Custom Statistics
-
-
-DPDK Extended Statistics API allows PMD to expose unique set of statistics.
-The Extended statistics are implemented and supported only for DPDK physical
-and vHost ports. Custom statistics are dynamic set of counters which can
-vary depenend on a driver. Those statistics are implemented
-for DPDK physical ports and contain all "dropped", "error" and "management"
-counters from XSTATS. XSTATS counters list can be found here:
-`__.
-
-To enable statistics, you have to enable OpenFlow 1.4 support for OVS.
-Configure bridge br0 to support OpenFlow version 1.4::
-
-$ ovs-vsctl set bridge br0 datapath_type=netdev \
-  protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14
-
-Check the OVSDB protocols column in the bridge table if OpenFlow 1.4 support
-is enabled for OVS::
-
-$ ovsdb-client dump Bridge protocols
-
-Query the port statistics by explicitly specifying -O OpenFlow14 option::
-
-$ ovs-ofctl -O OpenFlow14 dump-ports br0
-
-Note about "Extended Statistics": vHost ports supports only partial
-statistics. RX packet size based counter are only supported and
-doesn't include TX packet size counters.
-
-EMC Insertion Probability
--
-By default 1 in every 100 flows are inserted into the Exact Match Cache (EMC).
-It is possible to change this insertion probability by setting the
-``emc-insert-inv-prob`` option::
-
-$ ovs-vsctl --no-wait set Open_vSwitch . other_config:emc-insert-inv-prob=N
-
-where:
-
-``N``
-  is a positive integer representing the inverse probability of insertion ie.
-  on average 1 in every N packets with a unique flow will generate an EMC
-  insertion.
-
-If ``N`` is set to 1, an insertion will be performed for every flow. If set to
-0, no insertions will be performed and the EMC will effectively be disabled.
-
-With default ``N`` set to 100, higher megaflow hits will occur initially
-as observed with pmd stats::
-
-$ ovs-appctl dpif-netdev/pmd-stats-show
-
-For certain traffic profiles with many parallel flows, it's recommended to set
-``N`` to '0' to achieve higher forwarding performance.
-
-For more information on the EMC refer to :doc:`/intro/install/dpdk` .
-
 .. _dpdk-ovs-in-guest:
 
 OVS with DPDK Inside VMs
diff --git a/Documentation/topics/dpdk/bridge.rst 
b/Documentation/topics/dpdk/bridge.rst
new file mode 100644
index 0..307005f3b
--- /dev/null
+++ b/Documentation/topics/dpdk/bridge.rst
@@ -0,0 +1,103 @@
+..
+  Licensed under the Apache License, Version 2.0 (the "License"); you may
+  not use this file except in compliance with the License. You may obtain
+  a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+  License for the specific language governing permissions and limitations
+  under the License.
+
+  Convention for heading levels in Open vSwitch documentation:
+
+  ===  Heading 0 (reserved for the title in a document)
+  ---  Heading 1
+  ~~~  Heading 2
+  +++  Heading 3
+  '''  Heading 4
+
+  Avoid deeper levels because they do not render well.
+
+
+DPDK Bridges
+
+
+The DPDK datapath requires specially configured bridge(s) in order to utilize
+DPDK-backed :doc:`physical ` and `virtual ` ports.
+
+Quick Example
+-
+
+This example demonstrates how to add a bridge using the DPDK datapath::
+
+$ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
+
+This assumes Open vSwitch has been built with DPDK support. Refer to
+:doc:`/intro/install/dpdk` for more information.
+
+.. _extended-statistics:
+
+Extended & Custom Statistics
+
+
+The DPDK Extended Statistics API allows PMDs to expose unique set 

[ovs-dev] [PATCH 4/8] doc: Move "QoS" guide to its own document

[Stephen Finucane]

Again, this stuff is too detailed for a high-level howto.

Signed-off-by: Stephen Finucane 
---
 Documentation/howto/dpdk.rst|  70 -
 Documentation/topics/dpdk/index.rst |   1 +
 Documentation/topics/dpdk/phy.rst   |   6 +++
 Documentation/topics/dpdk/qos.rst   | 100 
 4 files changed, 107 insertions(+), 70 deletions(-)
 create mode 100644 Documentation/topics/dpdk/qos.rst

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index 4d993a0eb..608dde814 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -85,76 +85,6 @@ To stop ovs-vswitchd & delete bridge, run::
 $ ovs-appctl -t ovsdb-server exit
 $ ovs-vsctl del-br br0
 
-QoS

-
-Assuming you have a vhost-user port transmitting traffic consisting of packets
-of size 64 bytes, the following command would limit the egress transmission
-rate of the port to ~1,000,000 packets per second::
-
-$ ovs-vsctl set port vhost-user0 qos=@newqos -- \
---id=@newqos create qos type=egress-policer other-config:cir=4600 \
-other-config:cbs=2048`
-
-To examine the QoS configuration of the port, run::
-
-$ ovs-appctl -t ovs-vswitchd qos/show vhost-user0
-
-To clear the QoS configuration from the port and ovsdb, run::
-
-$ ovs-vsctl destroy QoS vhost-user0 -- clear Port vhost-user0 qos
-
-Refer to vswitch.xml for more details on egress-policer.
-
-Rate Limiting
---
-
-Here is an example on Ingress Policing usage. Assuming you have a vhost-user
-port receiving traffic consisting of packets of size 64 bytes, the following
-command would limit the reception rate of the port to ~1,000,000 packets per
-second::
-
-$ ovs-vsctl set interface vhost-user0 ingress_policing_rate=368000 \
-ingress_policing_burst=1000`
-
-To examine the ingress policer configuration of the port::
-
-$ ovs-vsctl list interface vhost-user0
-
-To clear the ingress policer configuration from the port::
-
-$ ovs-vsctl set interface vhost-user0 ingress_policing_rate=0
-
-Refer to vswitch.xml for more details on ingress-policer.
-
-Flow Control
-
-
-Flow control can be enabled only on DPDK physical ports. To enable flow control
-support at tx side while adding a port, run::
-
-$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
-options:dpdk-devargs=:01:00.0 options:tx-flow-ctrl=true
-
-Similarly, to enable rx flow control, run::
-
-$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
-options:dpdk-devargs=:01:00.0 options:rx-flow-ctrl=true
-
-To enable flow control auto-negotiation, run::
-
-$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
-options:dpdk-devargs=:01:00.0 options:flow-ctrl-autoneg=true
-
-To turn ON the tx flow control at run time for an existing port, run::
-
-$ ovs-vsctl set Interface dpdk-p0 options:tx-flow-ctrl=true
-
-The flow control parameters can be turned off by setting ``false`` to the
-respective parameter. To disable the flow control at tx side, run::
-
-$ ovs-vsctl set Interface dpdk-p0 options:tx-flow-ctrl=false
-
 pdump
 -
 
diff --git a/Documentation/topics/dpdk/index.rst 
b/Documentation/topics/dpdk/index.rst
index dfde88377..fe4d97b8b 100644
--- a/Documentation/topics/dpdk/index.rst
+++ b/Documentation/topics/dpdk/index.rst
@@ -32,3 +32,4 @@ The DPDK Datapath
vhost-user
ring
pmd
+   qos
diff --git a/Documentation/topics/dpdk/phy.rst 
b/Documentation/topics/dpdk/phy.rst
index 507dac869..93aff628c 100644
--- a/Documentation/topics/dpdk/phy.rst
+++ b/Documentation/topics/dpdk/phy.rst
@@ -210,3 +210,9 @@ More information on the different types of virtual DPDK 
PMDs can be found in
 the `DPDK documentation`__.
 
 __ http://dpdk.org/doc/guides/nics/overview.html
+
+Flow Control
+
+
+Flow control is available for DPDK physical ports. For more information, refer
+to :ref:`dpdk-flow-control`.
diff --git a/Documentation/topics/dpdk/qos.rst 
b/Documentation/topics/dpdk/qos.rst
new file mode 100644
index 0..c19e01db7
--- /dev/null
+++ b/Documentation/topics/dpdk/qos.rst
@@ -0,0 +1,100 @@
+..
+  Licensed under the Apache License, Version 2.0 (the "License"); you may
+  not use this file except in compliance with the License. You may obtain
+  a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+  License for the specific language governing permissions and limitations
+  under the License.
+
+  Convention for heading levels in Open vSwitch documentation:
+
+  ===  Heading 0 (reserved for the title in a document)
+  ---  

[ovs-dev] [PATCH 0/8] Split up the DPDK howto

[Stephen Finucane]

The DPDK howto has slowly morphed into a catch all for everything DPDK,
which goes against the original design goal for 'howto' documents [*].
This series attempts to return some sanity to the universe by splitting
this document into many more 'topic' documents. Along the way, we add a
lot of semantic markup, rework some text, and add an overview on
'dpdk'-type ports (the original goal here).

There's a good chance I've made some mistakes in the process and I've
left TODOs for someone to resolve now or at a future date. I welcome
feedback on both of these.

Now to go back to figure how exactly NUMA affinity works for and affects
PMD threads...

[*] 'howto' documents are supposed to be brief, high-level overviews on
a particular group of features, with a focus on the user. They're
not as all-encompassing as a 'tutorial', but not as specific as a
'topic'.

Stephen Finucane (8):
  doc: Add an overview of the 'dpdk' port
  doc: Add "PMD" topic document
  doc: Move additional sections to "physical ports" doc
  doc: Move "QoS" guide to its own document
  doc: Add "bridge" topic document
  doc: Move "pdump" guide to its own document
  doc: Split Jumbo Frames guide between two docs
  doc: Final cleanup of the DPDK howto

 Documentation/conf.py|   2 +-
 Documentation/howto/dpdk.rst | 453 +++
 Documentation/topics/dpdk/bridge.rst | 103 +++
 Documentation/topics/dpdk/index.rst  |  11 +
 Documentation/topics/dpdk/pdump.rst  |  65 +
 Documentation/topics/dpdk/phy.rst| 242 +
 Documentation/topics/dpdk/pmd.rst| 139 ++
 Documentation/topics/dpdk/qos.rst| 100 +++
 Documentation/topics/dpdk/vhost-user.rst |  53 +++-
 9 files changed, 740 insertions(+), 428 deletions(-)
 create mode 100644 Documentation/topics/dpdk/bridge.rst
 create mode 100644 Documentation/topics/dpdk/pdump.rst
 create mode 100644 Documentation/topics/dpdk/phy.rst
 create mode 100644 Documentation/topics/dpdk/pmd.rst
 create mode 100644 Documentation/topics/dpdk/qos.rst

-- 
2.14.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 2/8] doc: Add "PMD" topic document

[Stephen Finucane]

This continues the breakup of the huge DPDK "howto" into smaller
components. There are a couple of related changes included, such as
using "Rx queue" instead of "rxq" and noting how Tx queues cannot be
configured.

We enable the TODO directive, so we can actually start calling out some
TODOs.

Signed-off-by: Stephen Finucane 
---
 Documentation/conf.py|   2 +-
 Documentation/howto/dpdk.rst |  86 ---
 Documentation/topics/dpdk/index.rst  |   1 +
 Documentation/topics/dpdk/phy.rst|  10 +++
 Documentation/topics/dpdk/pmd.rst| 139 +++
 Documentation/topics/dpdk/vhost-user.rst |  17 ++--
 6 files changed, 159 insertions(+), 96 deletions(-)
 create mode 100644 Documentation/topics/dpdk/pmd.rst

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 6ab144c5d..babda21de 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -32,7 +32,7 @@ needs_sphinx = '1.1'
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = []
+extensions = ['sphinx.ext.todo']
 
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']
diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index d717d2ebe..c2324118d 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -81,92 +81,6 @@ To stop ovs-vswitchd & delete bridge, run::
 $ ovs-appctl -t ovsdb-server exit
 $ ovs-vsctl del-br br0
 
-PMD Thread Statistics
--
-
-To show current stats::
-
-$ ovs-appctl dpif-netdev/pmd-stats-show
-
-To clear previous stats::
-
-$ ovs-appctl dpif-netdev/pmd-stats-clear
-
-Port/RXQ Assigment to PMD Threads
--
-
-To show port/rxq assignment::
-
-$ ovs-appctl dpif-netdev/pmd-rxq-show
-
-To change default rxq assignment to pmd threads, rxqs may be manually pinned to
-desired cores using::
-
-$ ovs-vsctl set Interface  \
-other_config:pmd-rxq-affinity=
-
-where:
-
--  is a CSV list of ``:`` values
-
-For example::
-
-$ ovs-vsctl set interface dpdk-p0 options:n_rxq=4 \
-other_config:pmd-rxq-affinity="0:3,1:7,3:8"
-
-This will ensure:
-
-- Queue #0 pinned to core 3
-- Queue #1 pinned to core 7
-- Queue #2 not pinned
-- Queue #3 pinned to core 8
-
-After that PMD threads on cores where RX queues was pinned will become
-``isolated``. This means that this thread will poll only pinned RX queues.
-
-.. warning::
-  If there are no ``non-isolated`` PMD threads, ``non-pinned`` RX queues will
-  not be polled. Also, if provided ``core_id`` is not available (ex. this
-  ``core_id`` not in ``pmd-cpu-mask``), RX queue will not be polled by any PMD
-  thread.
-
-If pmd-rxq-affinity is not set for rxqs, they will be assigned to pmds (cores)
-automatically. The processing cycles that have been stored for each rxq
-will be used where known to assign rxqs to pmd based on a round robin of the
-sorted rxqs.
-
-For example, in the case where here there are 5 rxqs and 3 cores (e.g. 3,7,8)
-available, and the measured usage of core cycles per rxq over the last
-interval is seen to be:
-
-- Queue #0: 30%
-- Queue #1: 80%
-- Queue #3: 60%
-- Queue #4: 70%
-- Queue #5: 10%
-
-The rxqs will be assigned to cores 3,7,8 in the following order:
-
-Core 3: Q1 (80%) |
-Core 7: Q4 (70%) | Q5 (10%)
-core 8: Q3 (60%) | Q0 (30%)
-
-To see the current measured usage history of pmd core cycles for each rxq::
-
-$ ovs-appctl dpif-netdev/pmd-rxq-show
-
-.. note::
-
-  A history of one minute is recorded and shown for each rxq to allow for
-  traffic pattern spikes. An rxq's pmd core cycles usage changes due to traffic
-  pattern or reconfig changes will take one minute before they are fully
-  reflected in the stats.
-
-Rxq to pmds assignment takes place whenever there are configuration changes
-or can be triggered by using::
-
-$ ovs-appctl dpif-netdev/pmd-rxq-rebalance
-
 QoS
 ---
 
diff --git a/Documentation/topics/dpdk/index.rst 
b/Documentation/topics/dpdk/index.rst
index 5f836a6e9..dfde88377 100644
--- a/Documentation/topics/dpdk/index.rst
+++ b/Documentation/topics/dpdk/index.rst
@@ -31,3 +31,4 @@ The DPDK Datapath
phy
vhost-user
ring
+   pmd
diff --git a/Documentation/topics/dpdk/phy.rst 
b/Documentation/topics/dpdk/phy.rst
index 1c18e4e3d..222fa3e9f 100644
--- a/Documentation/topics/dpdk/phy.rst
+++ b/Documentation/topics/dpdk/phy.rst
@@ -109,3 +109,13 @@ tool::
 For more information, refer to the `DPDK documentation `__.
 
 .. _dpdk-drivers: http://dpdk.org/doc/guides/linux_gsg/linux_drivers.html
+
+Multiqueue
+--
+
+Poll Mode Driver (PMD) threads are the threads that do the heavy lifting for
+the DPDK datapath. Correct configuration of PMD threads and the Rx queues they
+utilize is a requirement in order to deliver the 

[ovs-dev] [PATCH 1/8] doc: Add an overview of the 'dpdk' port

[Stephen Finucane]

These ports are used to allow ingress/egress from the host and are
therefore _reasonably_ important. However, there is no clear overview of
what these ports actually are or why things are done the way they are.
Start closing this gap by providing a standalone example of using these
ports along with a little more detailed overview of the binding process.

There is additional cleanup to be done for the DPDK howto, but that will
be done separately.

Signed-off-by: Stephen Finucane 
Cc: Ciara Loftus 
Cc: Kevin Traynor 
---
 Documentation/topics/dpdk/index.rst |   1 +
 Documentation/topics/dpdk/phy.rst   | 111 
 2 files changed, 112 insertions(+)
 create mode 100644 Documentation/topics/dpdk/phy.rst

diff --git a/Documentation/topics/dpdk/index.rst 
b/Documentation/topics/dpdk/index.rst
index da148b323..5f836a6e9 100644
--- a/Documentation/topics/dpdk/index.rst
+++ b/Documentation/topics/dpdk/index.rst
@@ -28,5 +28,6 @@ The DPDK Datapath
 .. toctree::
:maxdepth: 2
 
+   phy
vhost-user
ring
diff --git a/Documentation/topics/dpdk/phy.rst 
b/Documentation/topics/dpdk/phy.rst
new file mode 100644
index 0..1c18e4e3d
--- /dev/null
+++ b/Documentation/topics/dpdk/phy.rst
@@ -0,0 +1,111 @@
+..
+  Copyright 2018, Red Hat, Inc.
+
+  Licensed under the Apache License, Version 2.0 (the "License"); you may
+  not use this file except in compliance with the License. You may obtain
+  a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+  License for the specific language governing permissions and limitations
+  under the License.
+
+  Convention for heading levels in Open vSwitch documentation:
+
+  ===  Heading 0 (reserved for the title in a document)
+  ---  Heading 1
+  ~~~  Heading 2
+  +++  Heading 3
+  '''  Heading 4
+
+  Avoid deeper levels because they do not render well.
+
+===
+DPDK Physical Ports
+===
+
+The DPDK datapath provides a way to attach DPDK-backed physical interfaces to
+allow high-performance ingress/egress from the host.
+
+.. versionchanged:: 2.7.0
+
+   Before Open vSwitch 2.7.0, it was necessary to prefix port names with a
+   ``dpdk`` prefix. Starting with 2.7.0, this is no longer necessary.
+
+Quick Example
+-
+
+This example demonstrates how to bind two ``dpdk`` ports, bound to physical
+interfaces identified by hardware IDs ``:01:00.0`` and ``:01:00.1``, to
+an existing bridge called ``br0``::
+
+$ ovs-vsctl add-port br0 dpdk-p0 \
+   -- set Interface dpdk-p0 type=dpdk options:dpdk-devargs=:01:00.0
+$ ovs-vsctl add-port br0 dpdk-p1 \
+   -- set Interface dpdk-p1 type=dpdk options:dpdk-devargs=:01:00.1
+
+For the above example to work, the two physical interfaces must be bound to
+the DPDK poll-mode drivers in userspace rather than the traditional kernel
+drivers. See the `binding NIC drivers ` section for details.
+
+.. _dpdk-binding-nics:
+
+Binding NIC Drivers
+---
+
+DPDK operates entirely in userspace and, as a result, requires use of its own
+poll-mode drivers in user space for physical interfaces and a passthrough-style
+driver for the devices in kernel space.
+
+There are two different tools for binding drivers: :command:`driverctl` which
+is a generic tool for persistently configuring alternative device drivers, and
+:command:`dpdk-devbind` which is a DPDK-specific tool and whose changes do not
+persist across reboots. In addition, there are two options available for this
+kernel space driver - VFIO (Virtual Function I/O) and UIO (Userspace I/O) -
+along with a number of drivers for each option. We will demonstrate examples of
+both tools and will use the ``vfio-pci`` driver, which is the more secure,
+robust driver of those available. More information can be found in the `DPDK
+documentation `__.
+
+To list devices using :command:`driverctl`, run::
+
+$ driverctl -v list-devices | grep -i net
+:07:00.0 igb (I350 Gigabit Network Connection (Ethernet Server Adapter 
I350-T2))
+:07:00.1 igb (I350 Gigabit Network Connection (Ethernet Server Adapter 
I350-T2))
+
+You can then bind one or more of these devices using the same tool::
+
+$ driverctl set-override :07:00.0 vfio-pci
+
+Alternatively, to list devices using :command:`dpdk-devbind`, run::
+
+$ dpdk-devbind --status
+Network devices using DPDK-compatible driver
+
+
+
+Network devices using kernel driver
+===
+:07:00.0 'I350 Gigabit Network Connection 1521' 

[ovs-dev] [PATCH 6/8] doc: Move "pdump" guide to its own document

[Stephen Finucane]

Signed-off-by: Stephen Finucane 
---
 Documentation/howto/dpdk.rst| 39 --
 Documentation/topics/dpdk/index.rst |  7 
 Documentation/topics/dpdk/pdump.rst | 65 +
 3 files changed, 72 insertions(+), 39 deletions(-)
 create mode 100644 Documentation/topics/dpdk/pdump.rst

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index c01bf7a39..1a72e90bf 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -85,45 +85,6 @@ To stop ovs-vswitchd & delete bridge, run::
 $ ovs-appctl -t ovsdb-server exit
 $ ovs-vsctl del-br br0
 
-pdump
--
-
-pdump allows you to listen on DPDK ports and view the traffic that is passing
-on them. To use this utility, one must have libpcap installed on the system.
-Furthermore, DPDK must be built with ``CONFIG_RTE_LIBRTE_PDUMP=y`` and
-``CONFIG_RTE_LIBRTE_PMD_PCAP=y``.
-
-.. warning::
-  A performance decrease is expected when using a monitoring application like
-  the DPDK pdump app.
-
-To use pdump, simply launch OVS as usual, then navigate to the ``app/pdump``
-directory in DPDK, ``make`` the application and run like so::
-
-$ sudo ./build/app/dpdk-pdump -- \
---pdump port=0,queue=0,rx-dev=/tmp/pkts.pcap \
---server-socket-path=/usr/local/var/run/openvswitch
-
-The above command captures traffic received on queue 0 of port 0 and stores it
-in ``/tmp/pkts.pcap``. Other combinations of port numbers, queues numbers and
-pcap locations are of course also available to use. For example, to capture all
-packets that traverse port 0 in a single pcap file::
-
-$ sudo ./build/app/dpdk-pdump -- \
---pdump 'port=0,queue=*,rx-dev=/tmp/pkts.pcap,tx-dev=/tmp/pkts.pcap' \
---server-socket-path=/usr/local/var/run/openvswitch
-
-``server-socket-path`` must be set to the value of ``ovs_rundir()`` which
-typically resolves to ``/usr/local/var/run/openvswitch``.
-
-Many tools are available to view the contents of the pcap file. Once example is
-tcpdump. Issue the following command to view the contents of ``pkts.pcap``::
-
-$ tcpdump -r pkts.pcap
-
-More information on the pdump app and its usage can be found in the `DPDK docs
-`__.
-
 Jumbo Frames
 
 
diff --git a/Documentation/topics/dpdk/index.rst 
b/Documentation/topics/dpdk/index.rst
index 52cacaef6..c9b231f06 100644
--- a/Documentation/topics/dpdk/index.rst
+++ b/Documentation/topics/dpdk/index.rst
@@ -27,10 +27,17 @@ The DPDK Datapath
 
 .. toctree::
:maxdepth: 2
+   :caption: Bridges and Ports
 
bridge
phy
vhost-user
ring
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Advanced Configuration
+
pmd
qos
+   pdump
diff --git a/Documentation/topics/dpdk/pdump.rst 
b/Documentation/topics/dpdk/pdump.rst
new file mode 100644
index 0..f1a408989
--- /dev/null
+++ b/Documentation/topics/dpdk/pdump.rst
@@ -0,0 +1,65 @@
+..
+  Licensed under the Apache License, Version 2.0 (the "License"); you may
+  not use this file except in compliance with the License. You may obtain
+  a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+  License for the specific language governing permissions and limitations
+  under the License.
+
+  Convention for heading levels in Open vSwitch documentation:
+
+  ===  Heading 0 (reserved for the title in a document)
+  ---  Heading 1
+  ~~~  Heading 2
+  +++  Heading 3
+  '''  Heading 4
+
+  Avoid deeper levels because they do not render well.
+
+=
+pdump
+=
+
+pdump allows you to listen on DPDK ports and view the traffic that is passing
+on them. To use this utility, one must have libpcap installed on the system.
+Furthermore, DPDK must be built with ``CONFIG_RTE_LIBRTE_PDUMP=y`` and
+``CONFIG_RTE_LIBRTE_PMD_PCAP=y``.
+
+.. warning::
+
+   A performance decrease is expected when using a monitoring application like
+   the DPDK pdump app.
+
+To use pdump, simply launch OVS as usual, then navigate to the ``app/pdump``
+directory in DPDK, ``make`` the application and run like so::
+
+$ sudo ./build/app/dpdk-pdump -- \
+--pdump port=0,queue=0,rx-dev=/tmp/pkts.pcap \
+--server-socket-path=/usr/local/var/run/openvswitch
+
+The above command captures traffic received on queue 0 of port 0 and stores it
+in ``/tmp/pkts.pcap``. Other combinations of port numbers, queues numbers and
+pcap locations are of course also available to use. For example, to capture all
+packets that traverse port 0 in a single pcap file::
+
+$ sudo ./build/app/dpdk-pdump -- \
+--pdump 

[ovs-dev] [PATCH 3/8] doc: Move additional sections to "physical ports" doc

[Stephen Finucane]

The "vdev", "hotplugging", and "Rx checksum offload" sections only apply
to 'dpdk' ports and are too detailed to include in a high-level howto.
Move them, reworking some aspects of this in the process.

Signed-off-by: Stephen Finucane 
---
 Documentation/howto/dpdk.rst  | 93 +++
 Documentation/topics/dpdk/phy.rst | 91 ++
 2 files changed, 97 insertions(+), 87 deletions(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index c2324118d..4d993a0eb 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -57,8 +57,12 @@ usage is suggested::
 $ ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk \
 options:dpdk-devargs="class=eth,mac=00:11:22:33:44:55:02"
 
-Note: such syntax won't support hotplug. The hotplug is supposed to work with
-future DPDK release, v18.05.
+.. important::
+
+Hotplugging physical interfaces is not supported using the above syntax.
+This is expected to change with the release of DPDK v18.05. For information
+on hotplugging physical interfaces, you should instead refer to
+:ref:`port-hotplug`.
 
 After the DPDK ports get added to switch, a polling thread continuously polls
 DPDK devices and consumes 100% of the core, as can be checked from ``top`` and
@@ -236,16 +240,6 @@ largest frame size supported by Fortville NIC using the 
DPDK i40e driver, but
 larger frames and other DPDK NIC drivers may be supported. These cases are
 common for use cases involving East-West traffic only.
 
-Rx Checksum Offload

-
-By default, DPDK physical ports are enabled with Rx checksum offload.
-
-Rx checksum offload can offer performance improvement only for tunneling
-traffic in OVS-DPDK because the checksum validation of tunnel packets is
-offloaded to the NIC. Also enabling Rx checksum may slightly reduce the
-performance of non-tunnel traffic, specifically for smaller size packet.
-
 .. _extended-statistics:
 
 Extended & Custom Statistics
@@ -278,81 +272,6 @@ Note about "Extended Statistics": vHost ports supports 
only partial
 statistics. RX packet size based counter are only supported and
 doesn't include TX packet size counters.
 
-.. _port-hotplug:
-
-Port Hotplug
-
-
-OVS supports port hotplugging, allowing the use of 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-vsctl add-port br0 dpdkx -- set Interface dpdkx type=dpdk \
-options:dpdk-devargs=:01:00.0
-
-Detaching will be performed while processing del-port command::
-
-$ ovs-vsctl del-port dpdkx
-
-Sometimes, the del-port command may not detach the device.
-Detaching can be confirmed by the appearance of an INFO log.
-For example::
-
-INFO|Device ':04:00.1' has been detached
-
-If the log is not seen, then the port can be detached using::
-
-$ ovs-appctl netdev-dpdk/detach :01:00.0
-
-Detaching can be confirmed by console output::
-
-Device ':04:00.1' has been detached
-
-.. warning::
-Detaching should not be done if a device is known to be non-detachable, as
-this may cause the device to behave improperly when added back with
-add-port. The Chelsio Terminator adapters which use the cxgbe driver seem
-to be an example of this behavior; check the driver documentation if this
-is suspected.
-
-This feature does not work with some NICs.
-For more information please refer to the `DPDK Port Hotplug Framework
-`__.
-
-.. _vdev-support:
-
-Vdev Support
-
-
-DPDK provides drivers for both physical and virtual devices. Physical DPDK
-devices are added to OVS by specifying a valid PCI address in 'dpdk-devargs'.
-Virtual DPDK devices which do not have PCI addresses can be added using a
-different format for 'dpdk-devargs'.
-
-Typically, the format expected is 'eth_' where 'x' is a
-unique identifier of your choice for the given port.
-
-For example to add a dpdk port that uses the 'null' DPDK PMD driver::
-
-   $ ovs-vsctl add-port br0 null0 -- set Interface null0 type=dpdk \
-   options:dpdk-devargs=eth_null0
-
-Similarly, to add a dpdk port that uses the 'af_packet' DPDK PMD driver::
-
-   $ ovs-vsctl add-port br0 myeth0 -- set Interface myeth0 type=dpdk \
-   options:dpdk-devargs=eth_af_packet0,iface=eth0
-
-More information on the different types of virtual DPDK PMDs can be found in
-the `DPDK documentation
-`__.
-
-Note: Not all DPDK virtual PMD drivers have been tested and verified to work.
-
 EMC Insertion Probability
 -
 By default 1 in every 100 flows are inserted into the 

[ovs-dev] [PATCH 8/8] doc: Final cleanup of the DPDK howto

[Stephen Finucane]

This concludes the cleanup by fixing some grammar nits and adding some
additional cross-references.

Signed-off-by: Stephen Finucane 
---
 Documentation/howto/dpdk.rst | 61 ++--
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index ba01810f8..89e068748 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -25,23 +25,26 @@
 Using Open vSwitch with DPDK
 
 
-This document describes how to use Open vSwitch with DPDK datapath.
+This document describes how to use Open vSwitch with DPDK datapath. For more
+detailed information, refer to the various :doc:`DPDK topic guides
+`.
 
 .. important::
 
Using the DPDK datapath requires building OVS with DPDK support. Refer to
:doc:`/intro/install/dpdk` for more information.
 
-Ports and Bridges
--
+Overview
+
 
-ovs-vsctl can be used to set up bridges and other Open vSwitch features.
-Bridges should be created with a ``datapath_type=netdev``::
+:program:`ovs-vsctl` can be used to set up bridges and other Open vSwitch
+features.  Bridges should be created with a ``datapath_type=netdev``::
 
 $ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
 
-ovs-vsctl can also be used to add DPDK devices. ovs-vswitchd should print the
-number of dpdk devices found in the log file::
+:program:`ovs-vsctl` can also be used to add DPDK devices.
+:program:`ovs-vswitchd` should print the number of ``dpdk`` devices found in
+the log file::
 
 $ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
 options:dpdk-devargs=:01:00.0
@@ -59,14 +62,13 @@ is suggested::
 
 .. important::
 
-Hotplugging physical interfaces is not supported using the above syntax.
-This is expected to change with the release of DPDK v18.05. For information
-on hotplugging physical interfaces, you should instead refer to
-:ref:`port-hotplug`.
+Hotplugging physical interfaces is not supported for these devices.  This
+is expected to change with the release of DPDK v18.05. For information on
+hotplugging physical interfaces, refer to :ref:`port-hotplug`.
 
 After the DPDK ports get added to switch, a polling thread continuously polls
-DPDK devices and consumes 100% of the core, as can be checked from ``top`` and
-``ps`` commands::
+DPDK devices and consumes 100% of the core, as can be checked from
+:command:`top` and :command:`ps` commands::
 
 $ top -H
 $ ps -eLo pid,psr,comm | grep pmd
@@ -79,7 +81,7 @@ set. For example::
 -- set Interface p0 type=dpdk options:dpdk-devargs=:01:00.0 \
 -- set Interface p1 type=dpdk options:dpdk-devargs=:01:00.1
 
-To stop ovs-vswitchd & delete bridge, run::
+To stop :program:`ovs-vswitchd` and delete the bridge, run::
 
 $ ovs-appctl -t ovs-vswitchd exit
 $ ovs-appctl -t ovsdb-server exit
@@ -126,7 +128,7 @@ Add a userspace bridge and two ``dpdk`` (PHY) ports::
 $ ovs-vsctl add-port br0 phy1 -- set Interface phy1 type=dpdk
   options:dpdk-devargs=:01:00.1 ofport_request=2
 
-Add test flows to forward packets betwen DPDK port 0 and port 1::
+Add test flows to forward packets between DPDK port 0 and port 1::
 
 # Clear current flows
 $ ovs-ofctl del-flows br0
@@ -137,13 +139,16 @@ Add test flows to forward packets betwen DPDK port 0 and 
port 1::
 
 Transmit traffic into either port. You should see it returned via the other.
 
+More information on the ``dpdk`` ports can be found in :doc:`/topics/dpdk/phy`.
+
 .. _dpdk-vhost-loopback:
 
 PHY-VM-PHY (vHost Loopback)
 ---
 
 Add a userspace bridge, two ``dpdk`` (PHY) ports, and two ``dpdkvhostuser``
-ports::
+ports. It is assumed that the physical ports are already bound to DPDK, as
+described in :ref:`dpdk-binding-nics`::
 
 # Add userspace bridge
 $ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
@@ -161,7 +166,7 @@ ports::
 $ ovs-vsctl add-port br0 dpdkvhostuser1 \
 -- set Interface dpdkvhostuser1 type=dpdkvhostuser ofport_request=4
 
-Add test flows to forward packets betwen DPDK devices and VM ports::
+Add test flows to forward packets between DPDK devices and VM ports::
 
 # Clear current flows
 $ ovs-ofctl del-flows br0
@@ -221,19 +226,7 @@ described in :ref:`dpdk-testpmd`. Once compiled, run the 
application::
 $ set fwd mac retry
 $ start
 
-When you finish testing, bind the vNICs back to kernel::
-
-$ $DPDK_DIR/usertools/dpdk-devbind.py --bind=virtio-pci :00:03.0
-$ $DPDK_DIR/usertools/dpdk-devbind.py --bind=virtio-pci :00:04.0
-
-.. note::
-
-  Valid PCI IDs must be passed in above example. The PCI IDs can be retrieved
-  like so::
-
-  $ $DPDK_DIR/usertools/dpdk-devbind.py --status
-
-More information on the dpdkvhostuser ports can be found in
+More information on the ``dpdkvhostuser`` 

Re: [ovs-dev] Quota list

[Edson Perico]

Hello

Please find attached quota list and give us your best price.

Best Regards,
Edson Perico___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] tests: Add system-dpdk-testsuite

[Rybka, MarcinX]

Hi Ian,

Thank you for your comments. See my comments inline below.

> -Original Message-
> From: Stokes, Ian
> Sent: Wednesday, January 31, 2018 11:40 AM
> To: Rybka, MarcinX ; d...@openvswitch.org
> Cc: Rybka, MarcinX 
> Subject: RE: [ovs-dev] [PATCH v2] tests: Add system-dpdk-testsuite
> 
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > boun...@openvswitch.org] On Behalf Of Marcin Rybka
> > Sent: Tuesday, January 2, 2018 2:36 PM
> > To: d...@openvswitch.org
> > Cc: Rybka, MarcinX 
> > Subject: [ovs-dev] [PATCH v2] tests: Add system-dpdk-testsuite
> >
> > New OVS-DPDK testsuite, which can be launched via `make check-dpdk`,
> > tests OVS using a DPDK datapath. The testsuite contains already initial
> tests:
> >  1. EAL init
> >  2. Add standard DPDK PHY port
> >  3. Add vhost-user-client port
> >
> > Signed-off-by: Marcin Rybka 
> > ---
> >  Documentation/topics/testing.rst | 19 
> >  tests/automake.mk| 17 +++
> >  tests/system-dpdk-macros.at  | 54
> +
> >  tests/system-dpdk-testsuite.at   | 25 
> >  tests/system-dpdk.at | 65
> > 
> >  5 files changed, 180 insertions(+)
> >  create mode 100644 tests/system-dpdk-macros.at  create mode 100644
> > tests/system-dpdk-testsuite.at  create mode 100644
> > tests/system-dpdk.at
> >
> > diff --git a/Documentation/topics/testing.rst
> > b/Documentation/topics/testing.rst
> > index a49336b..74e0d3f 100644
> > --- a/Documentation/topics/testing.rst
> > +++ b/Documentation/topics/testing.rst
> > @@ -297,6 +297,25 @@ To invoke the datapath testsuite with the
> > userspace datapath, run::
> >
> >  The results of the testsuite are in ``tests/system-userspace-
> > testsuite.dir``.
> >
> > +DPDK datapath
> > +'
> > +
> > +To test :doc:`/intro/install/dpdk` (i.e., the build was configured
> > +with ``--with-dpdk``,the ``DPDK`` is installed), run the testsuite
> > +and generate a report by using the ``check-dpdk`` target::
> > +
> > +$ make check-dpdk
> > +
> > +To see a list of all the available tests, run::
> > +
> > +$ make check-dpdk TESTSUITEFLAGS=--list
> > +
> > +These tests require a `DPDK supported NIC`_ and proper DPDK variables
> > +(``DPDK_DIR`` and ``DPDK_BUILD``). Moreover you need to load the
> > +required modules and bind the NIC to the DPDK-compatible driver.
> > +
> > +.. _DPDK supported NIC: http://dpdk.org/doc/nics
> > +
> 
> Hi Marcin,
> 
> Thanks for working on this, a few comments inline below.
> 
> These tests will require elevated privileges (root or sudo) on systems to be
> run, otherwise they will fail as memory will not be allocated etc. by 
> ovs-dpdk.
> 
> I'd like to see this called out explicitly in the documentation along with a 
> short
> explanation (it's obvious to those familiar with DPDK but we must assume a
> user may not be, also existing ovs unit test can be run without these
> privileges so someone might work from that assumption).

Such information is covered in a parent paragraphs (one level above and two 
levels above). However, I will add such information to the documentation 
explicitly.

> 
> In testing I also see the following error although it does not stop the test
> from running.
> 
> set /bin/sh './tests/system-dpdk-testsuite' -C tests
> AUTOTEST_PATH='utilities:vswitchd:ovsdb:vtep:tests::ovn/controller-
> vtep:ovn/northd:ovn/utilities:ovn/controller'  -j1; \ "$@" || (test X'' = Xyes
> && "$@" --recheck) Traceback (most recent call last):
>   File "", line 3, in 
>   File "/usr/lib64/python2.7/socket.py", line 228, in meth
> return getattr(self._sock,name)(*args)
> socket.error: [Errno 99] Cannot assign requested address
> 

I also see such error when running any other unit tests of OVS. 
So it's not related with my changes.

> >  Kernel datapath
> >  '''
> >
> > diff --git a/tests/automake.mk b/tests/automake.mk index
> > 8157641..7be5712
> > 100644
> > --- a/tests/automake.mk
> > +++ b/tests/automake.mk
> > @@ -5,10 +5,12 @@ EXTRA_DIST += \
> > $(SYSTEM_KMOD_TESTSUITE_AT) \
> > $(SYSTEM_USERSPACE_TESTSUITE_AT) \
> > $(SYSTEM_OFFLOADS_TESTSUITE_AT) \
> > +   $(SYSTEM_DPDK_TESTSUITE_AT) \
> > $(TESTSUITE) \
> > $(SYSTEM_KMOD_TESTSUITE) \
> > $(SYSTEM_USERSPACE_TESTSUITE) \
> > $(SYSTEM_OFFLOADS_TESTSUITE) \
> > +   $(SYSTEM_DPDK_TESTSUITE) \
> > tests/atlocal.in \
> > $(srcdir)/package.m4 \
> > $(srcdir)/tests/testsuite \
> > @@ -126,6 +128,12 @@ SYSTEM_OFFLOADS_TESTSUITE_AT = \
> > tests/system-offloads-traffic.at \
> > tests/system-offloads-testsuite.at
> >
> > +SYSTEM_DPDK_TESTSUITE_AT = \
> > +   tests/system-common-macros.at \
> > +   tests/system-dpdk-macros.at \
> > +   tests/system-dpdk-testsuite.at \
> > +   tests/system-dpdk.at
> > +
> >  

Re: [ovs-dev] [PATCH] ovn-controller: Fix crash when sending GARP when openflow disconnection.

[Mark Michelson]

I'm a little hesitant about the `sleep 3` in the test. However, I think 
it should be fine given the nature of the test and the hard-coded garp 
backoff timer.


Acked-by: Mark Michelson 

On 02/12/2018 02:17 AM, Guoshuai Li wrote:

This is call stack:
Program received signal SIGABRT, Aborted.
1  0x76a4f8e8 in __GI_abort () at abort.c:90
2  0x004765d6 in ofputil_protocol_to_ofp_version (protocol=) at lib/ofp-util.c:769
3  0x0047c19e in ofputil_encode_packet_out (po=po@entry=0x7fffa0e0, 
protocol=) at lib/ofp-util.c:7060
4  0x00410870 in send_garp (garp=0x83cfe0, 
current_time=current_time@entry=1200375400) at ovn/controller/pinctrl.c:1738
5  0x0041430f in send_garp_run (active_tunnels=, 
local_datapaths=0x7fffc0a0, chassis_index=, chassis=0x8194d0, 
br_int=, ctx=0x7fffc080) at ovn/controller/pinctrl.c:2069

Signed-off-by: Guoshuai Li 
---
  ovn/controller/pinctrl.c | 40 ++--
  tests/ovn.at | 14 ++
  2 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 14c95ff54..9537735cf 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -1071,27 +1071,31 @@ pinctrl_run(struct controller_ctx *ctx,
  
  rconn_run(swconn);
  
-if (rconn_is_connected(swconn)) {

-if (conn_seq_no != rconn_get_connection_seqno(swconn)) {
-pinctrl_setup(swconn);
-conn_seq_no = rconn_get_connection_seqno(swconn);
-flush_put_mac_bindings();
-}
-
-/* Process a limited number of messages per call. */
-for (int i = 0; i < 50; i++) {
-struct ofpbuf *msg = rconn_recv(swconn);
-if (!msg) {
-break;
-}
+if (!rconn_is_connected(swconn)) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+VLOG_WARN_RL(, "%s is not connected.", rconn_get_target(swconn));
+return;
+}
  
-const struct ofp_header *oh = msg->data;

-enum ofptype type;
+if (conn_seq_no != rconn_get_connection_seqno(swconn)) {
+pinctrl_setup(swconn);
+conn_seq_no = rconn_get_connection_seqno(swconn);
+flush_put_mac_bindings();
+}
  
-ofptype_decode(, oh);

-pinctrl_recv(oh, type, ctx);
-ofpbuf_delete(msg);
+/* Process a limited number of messages per call. */
+for (int i = 0; i < 50; i++) {
+struct ofpbuf *msg = rconn_recv(swconn);
+if (!msg) {
+break;
  }
+
+const struct ofp_header *oh = msg->data;
+enum ofptype type;
+
+ofptype_decode(, oh);
+pinctrl_recv(oh, type, ctx);
+ofpbuf_delete(msg);
  }
  
  run_put_mac_bindings(ctx);

diff --git a/tests/ovn.at b/tests/ovn.at
index 00d26e757..67df0a8df 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -3566,6 +3566,20 @@ AT_CHECK([ovs-vsctl add-port br-int localvif1 -- set 
Interface localvif1 externa
  echo 
"f00108060001080006040001f001c0a80102c0a80102"
 > expected
  OVN_CHECK_PACKETS([hv/snoopvif-tx.pcap], [expected])
  
+# delete openflow connection.

+as hv
+OVS_APP_EXIT_AND_WAIT([ovs-vswitchd])
+
+# Wait for send Garp.
+sleep 3
+
+# check ovn-controller status.
+as hv
+AT_CHECK([ovs-appctl -t ovn-controller version | wc -l], [0], [1
+])
+
+start_daemon ovs-vswitchd --enable-dummy=system -vvconn -vofproto_dpif 
-vunixctl
+
  # Delete the localnet ports.
  AT_CHECK([ovs-vsctl del-port localvif1])
  AT_CHECK([ovn-nbctl lsp-del ln_port])



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH V2 00/10] Upstream Linux bug fixes for datapath

[Gregory Rose]

On 2/12/2018 12:34 AM, Pravin Shelar wrote:

On Wed, Feb 7, 2018 at 7:30 AM, Greg Rose  wrote:

Reorganized patch set that includes bug fixes and compatability
layer changes that can be backported to 2.9 as well as applied
to master.

V2 of these patches include suggested changes from the first patch
set.

Arnd Bergmann (1):
   datapath: use ktime_get_ts64() instead of ktime_get_ts()

Christophe JAILLET (1):
   datapath:  Fix an error handling path in
 'ovs_nla_init_match_and_action()

Florian Westphal (1):
   datapath: conntrack: make protocol tracker pointers const

Greg Rose (5):
   datapath: Fix netdev_master_upper_dev_link for 4.14
   compat: Do not include headers when not compiling
   compat:inet_frag.h: Check for frag_percpu_counter_batch
   datapath: Fix SKB_GSO_UDP usage
   compat: Fix compiler headers

Gustavo A. R. Silva (1):
   datapath: fix data type in queue_gso_packets

zhangliping (1):
   datapath: fix the incorrect flow action alloc size


I pushed this series to master and branch 2.9.


Thanks.


Thanks Pravin!

- Greg
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 2/2] Measure performance of ovn-controller loop.

[Mark Michelson]

On 02/09/2018 07:36 PM, Han Zhou wrote:

Looks a great tool! Just some minor comments:

On Fri, Feb 9, 2018 at 3:00 PM, Mark Michelson > wrote:

 >
 > This modifies ovn-controller to measure the amount of time it takes to
 > detect a change in the southbound database, generate the resulting flow
 > table, and write the flow table down to vswitchd.

The comment is a little inaccurate. The change cannot guarantee 
measurement of "write the flow table down to vswitchd", since sending 
the flow-adding messages to vswitchd could be performed in multiple 
iterations of the main loop, depending on the buffering status of 
vconn_send(). If it can't be completed in one round, the message 
sendings will continue in next loops in ofctrl_run().


Thanks for the review Han. I attempted to account for this in the code 
by only ending the sample in the case that ofctrl_can_put() returns 
true. This way, we might start a measurement in one loop iteration, but 
the measurement might not end until a later iteration if 
ofctrl_can_put() returns false. Do you have suggestions for other 
factors that I should take into account for determining when to end a 
measurement?





 >
 > The statistics can be queried using:
 >
 > ovs-appctl -t ovn-controller performance/show ovn-controller-loop
 >
 > Signed-off-by: Mark Michelson >

 > ---
 >  ovn/controller/ovn-controller.c | 17 +
 >  1 file changed, 17 insertions(+)
 >
 > diff --git a/ovn/controller/ovn-controller.c 
b/ovn/controller/ovn-controller.c

 > index 7592bda25..b9f8950d4 100644
 > --- a/ovn/controller/ovn-controller.c
 > +++ b/ovn/controller/ovn-controller.c
 > @@ -57,6 +57,9 @@
 >  #include "stream.h"
 >  #include "unixctl.h"
 >  #include "util.h"
 > +#include "timeval.h"
 > +#include "timer.h"
 > +#include "performance.h"
 >
 >  VLOG_DEFINE_THIS_MODULE(main);
 >
 > @@ -67,6 +70,8 @@ static unixctl_cb_func inject_pkt;
 >  #define DEFAULT_BRIDGE_NAME "br-int"
 >  #define DEFAULT_PROBE_INTERVAL_MSEC 5000
 >
 > +#define CONTROLLER_LOOP_PERFORMANCE_NAME "ovn-controller-loop"
 > +
 >  static void update_probe_interval(struct controller_ctx *,
 >                                    const char *ovnsb_remote);
 >  static void parse_options(int argc, char *argv[]);
 > @@ -639,8 +644,10 @@ main(int argc, char *argv[])
 >      unixctl_command_register("inject-pkt", "MICROFLOW", 1, 1, 
inject_pkt,

 >                               _pkt);
 >
 > +    performance_create(CONTROLLER_LOOP_PERFORMANCE_NAME, PERF_MS);
 >      /* Main loop. */
 >      exiting = false;
 > +    unsigned int our_seqno = 0;
 >      while (!exiting) {
 >          /* Check OVN SB database. */
 >          char *new_ovnsb_remote = get_ovnsb_remote(ovs_idl_loop.idl);
 > @@ -659,6 +666,12 @@ main(int argc, char *argv[])
 >              .ovnsb_idl_txn = ovsdb_idl_loop_run(_idl_loop),
 >          };
 >
 > +        if (our_seqno != ovsdb_idl_get_seqno(ctx.ovnsb_idl)) {

Shall we measure when there is no SB change, too? E.g. the loop can be 
triggered by local ovs-idl change, or by pin-ctrl messages, and these 
changes will trigger all the flow computations, which contributes a 
significant cost in ovn-controller, so I think we'd better measure them 
as well. I am working on an incremental processing framework which would 
avoid this kind of unnecessary recompute. I hope with this tool the 
improvements can be measured accurately :)


 > +            performance_start_sample(CONTROLLER_LOOP_PERFORMANCE_NAME,
 > +                                     time_msec());
 > +            our_seqno = ovsdb_idl_get_seqno(ctx.ovnsb_idl);
 > +        }
 > +
 >          update_probe_interval(, ovnsb_remote);
 >
 >          update_ssl_config(ctx.ovs_idl);
 > @@ -728,6 +741,9 @@ main(int argc, char *argv[])
 >                      ofctrl_put(_table, _ct_zones,
 >                                 get_nb_cfg(ctx.ovnsb_idl));
 >
 > +   
  performance_end_sample(CONTROLLER_LOOP_PERFORMANCE_NAME,

 > +                                           time_msec());
 > +
 >                      hmap_destroy(_table);
 >                  }
 >                  if (ctx.ovnsb_idl_txn) {
 > @@ -792,6 +808,7 @@ main(int argc, char *argv[])
 >              ofctrl_wait();
 >              pinctrl_wait();
 >          }
 > +
 >          ovsdb_idl_loop_commit_and_wait(_idl_loop);
 >
 >          if (ovsdb_idl_loop_commit_and_wait(_idl_loop) == 1) {
 > --
 > 2.13.6
 >
 > ___
 > dev mailing list
 > d...@openvswitch.org 
 > https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Acked-by: Han Zhan >


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH V2 00/10] Upstream Linux bug fixes for datapath

[Pravin Shelar]

On Wed, Feb 7, 2018 at 7:30 AM, Greg Rose  wrote:
> Reorganized patch set that includes bug fixes and compatability
> layer changes that can be backported to 2.9 as well as applied
> to master.
>
> V2 of these patches include suggested changes from the first patch
> set.
>
> Arnd Bergmann (1):
>   datapath: use ktime_get_ts64() instead of ktime_get_ts()
>
> Christophe JAILLET (1):
>   datapath:  Fix an error handling path in
> 'ovs_nla_init_match_and_action()
>
> Florian Westphal (1):
>   datapath: conntrack: make protocol tracker pointers const
>
> Greg Rose (5):
>   datapath: Fix netdev_master_upper_dev_link for 4.14
>   compat: Do not include headers when not compiling
>   compat:inet_frag.h: Check for frag_percpu_counter_batch
>   datapath: Fix SKB_GSO_UDP usage
>   compat: Fix compiler headers
>
> Gustavo A. R. Silva (1):
>   datapath: fix data type in queue_gso_packets
>
> zhangliping (1):
>   datapath: fix the incorrect flow action alloc size
>

I pushed this series to master and branch 2.9.


Thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ovn-controller: Fix crash when sending GARP when openflow disconnection.

[Guoshuai Li]

This is call stack:
Program received signal SIGABRT, Aborted.
1  0x76a4f8e8 in __GI_abort () at abort.c:90
2  0x004765d6 in ofputil_protocol_to_ofp_version (protocol=) at lib/ofp-util.c:769
3  0x0047c19e in ofputil_encode_packet_out (po=po@entry=0x7fffa0e0, 
protocol=) at lib/ofp-util.c:7060
4  0x00410870 in send_garp (garp=0x83cfe0, 
current_time=current_time@entry=1200375400) at ovn/controller/pinctrl.c:1738
5  0x0041430f in send_garp_run (active_tunnels=, 
local_datapaths=0x7fffc0a0, chassis_index=, 
chassis=0x8194d0, br_int=, ctx=0x7fffc080) at 
ovn/controller/pinctrl.c:2069

Signed-off-by: Guoshuai Li 
---
 ovn/controller/pinctrl.c | 40 ++--
 tests/ovn.at | 14 ++
 2 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 14c95ff54..9537735cf 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -1071,27 +1071,31 @@ pinctrl_run(struct controller_ctx *ctx,
 
 rconn_run(swconn);
 
-if (rconn_is_connected(swconn)) {
-if (conn_seq_no != rconn_get_connection_seqno(swconn)) {
-pinctrl_setup(swconn);
-conn_seq_no = rconn_get_connection_seqno(swconn);
-flush_put_mac_bindings();
-}
-
-/* Process a limited number of messages per call. */
-for (int i = 0; i < 50; i++) {
-struct ofpbuf *msg = rconn_recv(swconn);
-if (!msg) {
-break;
-}
+if (!rconn_is_connected(swconn)) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+VLOG_WARN_RL(, "%s is not connected.", rconn_get_target(swconn));
+return;
+}
 
-const struct ofp_header *oh = msg->data;
-enum ofptype type;
+if (conn_seq_no != rconn_get_connection_seqno(swconn)) {
+pinctrl_setup(swconn);
+conn_seq_no = rconn_get_connection_seqno(swconn);
+flush_put_mac_bindings();
+}
 
-ofptype_decode(, oh);
-pinctrl_recv(oh, type, ctx);
-ofpbuf_delete(msg);
+/* Process a limited number of messages per call. */
+for (int i = 0; i < 50; i++) {
+struct ofpbuf *msg = rconn_recv(swconn);
+if (!msg) {
+break;
 }
+
+const struct ofp_header *oh = msg->data;
+enum ofptype type;
+
+ofptype_decode(, oh);
+pinctrl_recv(oh, type, ctx);
+ofpbuf_delete(msg);
 }
 
 run_put_mac_bindings(ctx);
diff --git a/tests/ovn.at b/tests/ovn.at
index 00d26e757..67df0a8df 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -3566,6 +3566,20 @@ AT_CHECK([ovs-vsctl add-port br-int localvif1 -- set 
Interface localvif1 externa
 echo 
"f00108060001080006040001f001c0a80102c0a80102"
 > expected
 OVN_CHECK_PACKETS([hv/snoopvif-tx.pcap], [expected])
 
+# delete openflow connection.
+as hv
+OVS_APP_EXIT_AND_WAIT([ovs-vswitchd])
+
+# Wait for send Garp.
+sleep 3
+
+# check ovn-controller status.
+as hv
+AT_CHECK([ovs-appctl -t ovn-controller version | wc -l], [0], [1
+])
+
+start_daemon ovs-vswitchd --enable-dummy=system -vvconn -vofproto_dpif 
-vunixctl
+
 # Delete the localnet ports.
 AT_CHECK([ovs-vsctl del-port localvif1])
 AT_CHECK([ovn-nbctl lsp-del ln_port])
-- 
2.13.2.windows.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev