[ovs-dev] [PATCH] ofctl_parse_target: Fix memory leaks if there is no usable protocol

2018-11-27 Thread Yifeng Sun 
When there is no usable protocol, ofctl_parse_flows__ returns without
properly freeing memory. A previous patch failed to fix this issue.
This patch fixes it.

Fixes: cefb937878b0f
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11406
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11408
Signed-off-by: Yifeng Sun 
---
 tests/oss-fuzz/ofctl_parse_target.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tests/oss-fuzz/ofctl_parse_target.c 
b/tests/oss-fuzz/ofctl_parse_target.c
index d4712a442477..b4db52f7ed48 100644
--- a/tests/oss-fuzz/ofctl_parse_target.c
+++ b/tests/oss-fuzz/ofctl_parse_target.c
@@ -22,7 +22,7 @@ ofctl_parse_flows__(struct ofputil_flow_mod *fms, size_t 
n_fms,
 
 if (!(usable_protocols & OFPUTIL_P_ANY)) {
 printf("no usable protocol\n");
-return;
+goto free;
 }
 for (i = 0; i < sizeof(enum ofputil_protocol) * CHAR_BIT; i++) {
 protocol = 1u << i;
@@ -40,7 +40,11 @@ ofctl_parse_flows__(struct ofputil_flow_mod *fms, size_t 
n_fms,
 
 msg = ofputil_encode_flow_mod(fm, protocol);
 ofpbuf_delete(msg);
+}
 
+free:
+for (i = 0; i < n_fms; i++) {
+struct ofputil_flow_mod *fm = [i];
 free(CONST_CAST(struct ofpact *, fm->ofpacts));
 minimatch_destroy(>match);
 }
@@ -62,7 +66,6 @@ ofctl_parse_flow(const char *input, int command)
 free(error);
 } else {
 ofctl_parse_flows__(, 1, usable_protocols);
-minimatch_destroy();
 }
 }
 
-- 
2.7.4

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

[ovs-dev] [PATCH] odp-util: Validate values of vid and pcp in push_vlan action

2018-11-27 Thread Yifeng Sun 
Oss-fuzz complains that 'vid << VLAN_VID_SHIFT' is causing an error of
"Undefined-shift in parse_odp_action". This is because an invalid
value of vid is passed in push_vlan. This patch adds validation to
the value of vid, in addition to the value of pcp.

Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11520
Signed-off-by: Yifeng Sun 
---
 lib/odp-util.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/odp-util.c b/lib/odp-util.c
index bb6669b37af9..1e8c5f194793 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -2282,6 +2282,10 @@ parse_odp_action(const char *s, const struct simap 
*port_names,
 , , , )
 || ovs_scan(s, "push_vlan(tpid=%i,vid=%i,pcp=%i,cfi=%i)%n",
 , , , , )) {
+if ((vid & ~(VLAN_VID_MASK >> VLAN_VID_SHIFT)) != 0
+|| (pcp & ~(VLAN_PCP_MASK >> VLAN_PCP_SHIFT)) != 0) {
+return -EINVAL;
+}
 push.vlan_tpid = htons(tpid);
 push.vlan_tci = htons((vid << VLAN_VID_SHIFT)
   | (pcp << VLAN_PCP_SHIFT)
-- 
2.7.4

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

[ovs-dev] [PATCH] ofp-parse: Fix bug that doesn't stop at null byte

2018-11-27 Thread Yifeng Sun 
At the end of string s when s[n] == '\0', strchr(delimiters, '\0')
returns a non-null value. As a result, this function reads beyond
the valid length of s and returns an erroneous length. This patch
fixes it.

Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11473
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11505
Signed-off-by: Yifeng Sun 
---
 lib/ofp-parse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/ofp-parse.c b/lib/ofp-parse.c
index a8b5a877c59e..fd008dd80e7d 100644
--- a/lib/ofp-parse.c
+++ b/lib/ofp-parse.c
@@ -259,7 +259,7 @@ parse_value(const char *s, const char *delimiters)
  *
  * strchr(s, '\0') returns s+strlen(s), so this test handles the null
  * terminator at the end of 's'.  */
-while (!strchr(delimiters, s[n])) {
+while (s[n] != '\0' && !strchr(delimiters, s[n])) {
 if (s[n] == '(') {
 int level = 0;
 do {
-- 
2.7.4

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

[ovs-dev] [patch v1 1/5] conntrack: Stop exporting internal datastructures.

2018-11-27 Thread Darrell Ball 
Remove the exporting of the main internal conntrack datastructure.
These are made static.  Also stop passing around a pointer parameter
to all the internal datastructures; only one or two is used
for a given code path and these can be referenced directly and passed
specifically where appropriate.

Signed-off-by: Darrell Ball 
---
 lib/conntrack-private.h |  29 +++
 lib/conntrack.c | 543 +---
 lib/conntrack.h | 106 ++
 lib/dpif-netdev.c   |  51 ++---
 tests/test-conntrack.c  |  26 ++-
 5 files changed, 348 insertions(+), 407 deletions(-)

diff --git a/lib/conntrack-private.h b/lib/conntrack-private.h
index a344801..27ece38 100644
--- a/lib/conntrack-private.h
+++ b/lib/conntrack-private.h
@@ -119,6 +119,35 @@ enum ct_conn_type {
 CT_CONN_TYPE_UN_NAT,
 };
 
+/* Locking:
+ *
+ * The connections are kept in different buckets, which are completely
+ * independent. The connection bucket is determined by the hash of its key.
+ *
+ * Each bucket has two locks. Acquisition order is, from outermost to
+ * innermost:
+ *
+ *cleanup_mutex
+ *lock
+ *
+ * */
+struct conntrack_bucket {
+/* Protects 'connections' and 'exp_lists'.  Used in the fast path */
+struct ct_lock lock;
+/* Contains the connections in the bucket, indexed by 'struct conn_key' */
+struct hmap connections OVS_GUARDED;
+/* For each possible timeout we have a list of connections. When the
+ * timeout of a connection is updated, we move it to the back of the list.
+ * Since the connection in a list have the same relative timeout, the list
+ * will be ordered, with the oldest connections to the front. */
+struct ovs_list exp_lists[N_CT_TM] OVS_GUARDED;
+
+/* Protects 'next_cleanup'. Used to make sure that there's only one thread
+ * performing the cleanup. */
+struct ovs_mutex cleanup_mutex;
+long long next_cleanup OVS_GUARDED;
+};
+
 struct ct_l4_proto {
 struct conn *(*new_conn)(struct conntrack_bucket *, struct dp_packet *pkt,
  long long now);
diff --git a/lib/conntrack.c b/lib/conntrack.c
index 974f985..82a8357 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -76,9 +76,44 @@ enum ct_alg_ctl_type {
 CT_ALG_CTL_SIP,
 };
 
-static bool conn_key_extract(struct conntrack *, struct dp_packet *,
- ovs_be16 dl_type, struct conn_lookup_ctx *,
- uint16_t zone);
+#define CONNTRACK_BUCKETS_SHIFT 8
+#define CONNTRACK_BUCKETS (1 << CONNTRACK_BUCKETS_SHIFT)
+/* Independent buckets containing the connections */
+struct conntrack_bucket buckets[CONNTRACK_BUCKETS];
+/* Salt for hashing a connection key. */
+uint32_t hash_basis;
+/* The thread performing periodic cleanup of the connection
+ * tracker */
+pthread_t clean_thread;
+/* Latch to destroy the 'clean_thread' */
+struct latch clean_thread_exit;
+/* Number of connections currently in the connection tracker. */
+atomic_count n_conn;
+/* Connections limit. When this limit is reached, no new connection
+ * will be accepted. */
+atomic_uint n_conn_limit;
+/* The following resources are referenced during nat connection
+ * creation and deletion. */
+struct hmap nat_conn_keys OVS_GUARDED;
+/* Hash table for alg expectations. Expectations are created
+ * by control connections to help create data connections. */
+struct hmap alg_expectations OVS_GUARDED;
+/* Used to lookup alg expectations from the control context. */
+struct hindex alg_expectation_refs OVS_GUARDED;
+/* Expiry list for alg expectations. */
+struct ovs_list alg_exp_list OVS_GUARDED;
+/* This lock is used during NAT connection creation and deletion;
+ * it is taken after a bucket lock and given back before that
+ * bucket unlock.
+ * This lock is similarly used to guard alg_expectations and
+ * alg_expectation_refs. If a bucket lock is also held during
+ * the normal code flow, then is must be taken first and released
+ * last.
+ */
+struct ct_rwlock resources_lock;
+
+static bool conn_key_extract(struct dp_packet *, ovs_be16 dl_type,
+ struct conn_lookup_ctx *, uint16_t zone);
 static uint32_t conn_key_hash(const struct conn_key *, uint32_t basis);
 static void conn_key_reverse(struct conn_key *);
 static void conn_key_lookup(struct conntrack_bucket *ctb,
@@ -101,23 +136,22 @@ static void set_label(struct dp_packet *, struct conn *,
 static void *clean_thread_main(void *f_);
 
 static struct nat_conn_key_node *
-nat_conn_keys_lookup(struct hmap *nat_conn_keys,
+nat_conn_keys_lookup(struct hmap *nat_conn_keys_,
  const struct conn_key *key,
  uint32_t basis);
 
 static bool
-nat_conn_keys_insert(struct hmap *nat_conn_keys,
+nat_conn_keys_insert(struct hmap *nat_conn_keys_,
  const struct conn *nat_conn,
  uint32_t hash_basis);
 
 static void
-nat_conn_keys_remove(struct hmap *nat_conn_keys,

[ovs-dev] [patch v1 3/5] conntrack: Make 'conn' lock protocol specific.

2018-11-27 Thread Darrell Ball 
For performance reasons, make 'conn' lock protocol specific.

Signed-off-by: Darrell Ball 
---
 lib/conntrack-private.h |  8 +++
 lib/conntrack-tcp.c | 43 +
 lib/conntrack.c | 56 -
 3 files changed, 83 insertions(+), 24 deletions(-)

diff --git a/lib/conntrack-private.h b/lib/conntrack-private.h
index 3d838e4..ac891cc 100644
--- a/lib/conntrack-private.h
+++ b/lib/conntrack-private.h
@@ -81,16 +81,11 @@ struct alg_exp_node {
 bool nat_rpl_dst;
 };
 
-struct OVS_LOCKABLE ct_ce_lock {
-struct ovs_mutex lock;
-};
-
 struct conn {
 struct conn_key key;
 struct conn_key rev_key;
 /* Only used for orig_tuple support. */
 struct conn_key master_key;
-struct ct_ce_lock lock;
 long long expiration;
 struct ovs_list exp_node;
 struct cmap_node cm_node;
@@ -142,6 +137,9 @@ struct ct_l4_proto {
   long long now);
 void (*conn_get_protoinfo)(const struct conn *,
struct ct_dpif_protoinfo *);
+void (*conn_lock)(struct conn *);
+void (*conn_unlock)(struct conn *);
+void (*conn_destroy)(struct conn *);
 };
 
 /* Timeouts: all the possible timeout states passed to update_expiration()
diff --git a/lib/conntrack-tcp.c b/lib/conntrack-tcp.c
index 19fdf1d..9805332 100644
--- a/lib/conntrack-tcp.c
+++ b/lib/conntrack-tcp.c
@@ -54,6 +54,7 @@ struct tcp_peer {
 struct conn_tcp {
 struct conn up;
 struct tcp_peer peer[2];
+struct ovs_mutex lock;
 };
 
 enum {
@@ -144,10 +145,34 @@ tcp_get_wscale(const struct tcp_header *tcp)
 return wscale;
 }
 
+static void
+tcp_conn_lock(struct conn *conn_)
+OVS_NO_THREAD_SAFETY_ANALYSIS
+{
+struct conn_tcp *conn = conn_tcp_cast(conn_);
+ovs_mutex_lock(>lock);
+}
+
+static void
+tcp_conn_unlock(struct conn *conn_)
+OVS_NO_THREAD_SAFETY_ANALYSIS
+{
+struct conn_tcp *conn = conn_tcp_cast(conn_);
+ovs_mutex_unlock(>lock);
+}
+
+static void
+tcp_conn_destroy(struct conn *conn_)
+{
+struct conn_tcp *conn = conn_tcp_cast(conn_);
+ovs_mutex_destroy(>lock);
+}
+
 static enum ct_update_res
 tcp_conn_update(struct conn *conn_, struct dp_packet *pkt, bool reply,
 long long now)
 {
+tcp_conn_lock(conn_);
 struct conn_tcp *conn = conn_tcp_cast(conn_);
 struct tcp_header *tcp = dp_packet_l4(pkt);
 /* The peer that sent 'pkt' */
@@ -156,20 +181,23 @@ tcp_conn_update(struct conn *conn_, struct dp_packet 
*pkt, bool reply,
 struct tcp_peer *dst = >peer[reply ? 0 : 1];
 uint8_t sws = 0, dws = 0;
 uint16_t tcp_flags = TCP_FLAGS(tcp->tcp_ctl);
+enum ct_update_res rc = CT_UPDATE_VALID;
 
 uint16_t win = ntohs(tcp->tcp_winsz);
 uint32_t ack, end, seq, orig_seq;
 uint32_t p_len = tcp_payload_length(pkt);
 
 if (tcp_invalid_flags(tcp_flags)) {
-return CT_UPDATE_INVALID;
+rc = CT_UPDATE_INVALID;
+goto out;
 }
 
 if (((tcp_flags & (TCP_SYN | TCP_ACK)) == TCP_SYN)
 && dst->state >= CT_DPIF_TCPS_FIN_WAIT_2
 && src->state >= CT_DPIF_TCPS_FIN_WAIT_2) {
 src->state = dst->state = CT_DPIF_TCPS_CLOSED;
-return CT_UPDATE_NEW;
+rc = CT_UPDATE_NEW;
+goto out;
 }
 
 if (src->wscale & CT_WSCALE_FLAG
@@ -385,10 +413,13 @@ tcp_conn_update(struct conn *conn_, struct dp_packet 
*pkt, bool reply,
 src->state = dst->state = CT_DPIF_TCPS_TIME_WAIT;
 }
 } else {
-return CT_UPDATE_INVALID;
+rc = CT_UPDATE_INVALID;
+goto out;
 }
 
-return CT_UPDATE_VALID;
+out:
+tcp_conn_unlock(conn_);
+return rc;
 }
 
 static bool
@@ -448,6 +479,7 @@ tcp_new_conn(struct dp_packet *pkt, long long now)
 src->state = CT_DPIF_TCPS_SYN_SENT;
 dst->state = CT_DPIF_TCPS_CLOSED;
 conn_init_expiration(>up, CT_TM_TCP_FIRST_PACKET, now);
+ovs_mutex_init_adaptive(>lock);
 
 return >up;
 }
@@ -490,4 +522,7 @@ struct ct_l4_proto ct_proto_tcp = {
 .valid_new = tcp_valid_new,
 .conn_update = tcp_conn_update,
 .conn_get_protoinfo = tcp_conn_get_protoinfo,
+.conn_lock = tcp_conn_lock,
+.conn_unlock = tcp_conn_unlock,
+.conn_destroy = tcp_conn_destroy,
 };
diff --git a/lib/conntrack.c b/lib/conntrack.c
index 182a651..d88732d 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -583,16 +583,43 @@ alg_src_ip_wc(enum ct_alg_ctl_type alg_ctl_type)
 }
 
 static void
+conn_entry_lock(struct conn *conn)
+{
+struct ct_l4_proto *class = l4_protos[conn->key.nw_proto];
+if (class->conn_lock) {
+class->conn_lock(conn);
+}
+}
+
+static void
+conn_entry_unlock(struct conn *conn)
+{
+struct ct_l4_proto *class = l4_protos[conn->key.nw_proto];
+if (class->conn_unlock) {
+class->conn_unlock(conn);
+}
+}
+
+static void
+conn_entry_destroy(struct conn *conn)
+{
+struct ct_l4_proto *class = l4_protos[conn->key.nw_proto];
+if

[ovs-dev] [patch v1 0/5] conntrack: Optimize and refactor.

2018-11-27 Thread Darrell Ball 
Patch 1 is not an optimization per se, but aimed at eliminating
the exporting of internal conntrack infra.

Patch 2 Add RCU support.  This is mainly done for performance 
reasons, but also simplifies the code.

Patch 3 Moves the conntrack entry locking to the L4 protocol
specific layers.  This is done for performance reasons and some
memory savings.

Patch 4 is mainly for memory savings for the most common cases, but
also increases performance for large number of flows (> 10).

Patch 5 is a performance optimization for recirculations.

This series starts at v1 although some parts were sent out earlier
as a single patch; that is because the earlier series stated that
the patch would later be split out and added to, hence that is an
implied RFC.  Also, this series brings in a couple new improvements
not in the original patch.

These patches presently include an updated version of the changes
for this series
https://patchwork.ozlabs.org/project/openvswitch/list/?series=78059
but those parts (approx 20 lines) will be later dropped from this
series and handled with the above mentioned series.

Darrell Ball (5):
  conntrack: Stop exporting internal datastructures.
  conntrack: Add rcu support.
  conntrack: Make 'conn' lock protocol specific.
  conntrack: Memory savings.
  conntrack: Optimize recirculations.

 lib/conntrack-icmp.c|   23 +-
 lib/conntrack-other.c   |   13 +-
 lib/conntrack-private.h |  110 ++--
 lib/conntrack-tcp.c |   64 ++-
 lib/conntrack.c | 1375 ++-
 lib/conntrack.h |  212 +---
 lib/dpif-netdev.c   |   51 +-
 lib/packets.h   |4 +
 tests/test-conntrack.c  |   26 +-
 9 files changed, 829 insertions(+), 1049 deletions(-)

-- 
1.9.1

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

[ovs-dev] Excel - Análisis de los estados financieros

2018-11-27 Thread Precio especial 
 

 ¡Taller Práctico - Innova learn! 

 

Nuestro webinar le permitirá al participante realizar un análisis profundo de 
la situación económica y financiera de
su organización en un momento determinado así como aplicar las principales 
herramientas de análisis e interpretación
de los indicadores económicos y financieros para obtener conclusiones válidas 
acerca de la solvencia y liquidez de la organización 

 

ESTA ES SU OPORTUNIDAD para participar en el WEBINAR INTERACTIVO "Elaboración 
de estados financieros con excel"

Con Innova Learn, en el cual podrás: 

 

-Analizar la situaciones económica financiera de su organización. 

- Analizar las causas de los resultados obtenidos, ya sean positivos o 
negativos y ser capaces de entender la motivación a fin de tomar decisiones. 

 

"Para determinar el potencial de desarrollo de nuestra empresa, es necesario 
realizar un análisis de los estados financieros".

Además te ofrecemos: 

 

Precio especial 

 

La cita es el próximo Viernes 14 de Diciembre en punto de las 10:00 am por 
nuestra plataforma web. 

 

Para mayor información, marcar a nuestro centro de atención a clientes: 

 

(045) 55 1554 6630 , o responder sobre este correo con la palabra FExcel + los 
siguientes datos:

NOMBRE:
TELÉFONO:
EMPRESA. :


 

¡Estamos en contacto!


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

[ovs-dev] [PATCH v3] netdev-dpdk: Add mbuf HEADROOM after alignment.

2018-11-27 Thread Tiago Lam 
Commit dfaf00e started using the result of dpdk_buf_size() to calculate
the available size on each mbuf, as opposed to using the previous
MBUF_SIZE macro. However, this was calculating the mbuf size by adding
up the MTU with RTE_PKTMBUF_HEADROOM and only then aligning to
NETDEV_DPDK_MBUF_ALIGN. Instead, the accounting for the
RTE_PKTMBUF_HEADROOM should only happen after alignment, as per below.

Before alignment:
ROUNDUP(MTU(1500) + RTE_PKTMBUF_HEADROOM(128), 1024) = 2048

After aligment:
ROUNDUP(MTU(1500), 1024) + 128 = 2176

This might seem insignificant, however, it might have performance
implications in DPDK, where each mbuf is expected to have 2k +
RTE_PKTMBUF_HEADROOM of available space. This is because not only some
NICs have course grained alignments of 1k, they will also take
RTE_PKTMBUF_HEADROOM bytes from the overall available space in an mbuf
when setting up their Rx requirements. Thus, only the "After alignment"
case above would guarantee a 2k of available room, as the "Before
alignment" would report only 1920B.

Some extra information can be found at:
https://mails.dpdk.org/archives/dev/2018-November/119219.html

Note: This has been found by Ian Stokes while going through some
af_packet checks.

Reported-by: Ian Stokes 
Fixes: dfaf00e ("netdev-dpdk: fix mbuf sizing")
Signed-off-by: Tiago Lam 
---
v3:
   - Take trailer_size into account when calculating mbuf size - Ian.

v2:
   - Rebase to master 85706c3 ("ovn: Avoid tunneling for VLAN packets
 redirected to a gateway chassis").

   - Fix mbuf size calculations under Documentation/topics/dpdk/memory.rst
 to take into account the header_size added to each mepool element (64
 bytes) - Ian.
---

 Documentation/topics/dpdk/memory.rst | 28 ++--
 lib/netdev-dpdk.c|  6 --
 2 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/Documentation/topics/dpdk/memory.rst 
b/Documentation/topics/dpdk/memory.rst
index c9b739f..9ebfd11 100644
--- a/Documentation/topics/dpdk/memory.rst
+++ b/Documentation/topics/dpdk/memory.rst
@@ -107,8 +107,8 @@ Example 1
 
  MTU = 1500 Bytes
  Number of mbufs = 262144
- Mbuf size = 2752 Bytes
- Memory required = 262144 * 2752 = 721 MB
+ Mbuf size = 3008 Bytes
+ Memory required = 262144 * 3008 = 788 MB
 
 Example 2
 +
@@ -116,8 +116,8 @@ Example 2
 
  MTU = 1800 Bytes
  Number of mbufs = 262144
- Mbuf size = 2752 Bytes
- Memory required = 262144 * 2752 = 721 MB
+ Mbuf size = 3008 Bytes
+ Memory required = 262144 * 3008 = 788 MB
 
 .. note::
 
@@ -130,8 +130,8 @@ Example 3
 
  MTU = 6000 Bytes
  Number of mbufs = 262144
- Mbuf size = 8000 Bytes
- Memory required = 262144 * 8000 = 2097 MB
+ Mbuf size = 7104 Bytes
+ Memory required = 262144 * 7104 = 1862 MB
 
 Example 4
 +
@@ -139,8 +139,8 @@ Example 4
 
  MTU = 9000 Bytes
  Number of mbufs = 262144
- Mbuf size = 10048 Bytes
- Memory required = 262144 * 10048 = 2634 MB
+ Mbuf size = 10176 Bytes
+ Memory required = 262144 * 10176 = 2667 MB
 
 Per Port Memory Calculations
 
@@ -194,8 +194,8 @@ Example 1: (1 rxq, 1 PMD, 1500 MTU)
 
  MTU = 1500
  Number of mbufs = (1 * 2048) + (2 * 2048) + (1 * 32) + (16384) = 22560
- Mbuf size = 2752 Bytes
- Memory required = 22560 * 2752 = 62 MB
+ Mbuf size = 3008 Bytes
+ Memory required = 22560 * 3008 = 67 MB
 
 Example 2: (1 rxq, 2 PMD, 6000 MTU)
 +++
@@ -203,8 +203,8 @@ Example 2: (1 rxq, 2 PMD, 6000 MTU)
 
  MTU = 6000
  Number of mbufs = (1 * 2048) + (3 * 2048) + (1 * 32) + (16384) = 24608
- Mbuf size = 8000 Bytes
- Memory required = 24608 * 8000 = 196 MB
+ Mbuf size = 7104 Bytes
+ Memory required = 24608 * 7104 = 175 MB
 
 Example 3: (2 rxq, 2 PMD, 9000 MTU)
 +++
@@ -212,5 +212,5 @@ Example 3: (2 rxq, 2 PMD, 9000 MTU)
 
  MTU = 9000
  Number of mbufs = (2 * 2048) + (3 * 2048) + (1 * 32) + (16384) = 26656
- Mbuf size = 10048 Bytes
- Memory required = 26656 * 10048 = 267 MB
+ Mbuf size = 10176 Bytes
+ Memory required = 26656 * 10176 = 271 MB
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index e8618a6..a871743 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -521,8 +521,8 @@ is_dpdk_class(const struct netdev_class *class)
 static uint32_t
 dpdk_buf_size(int mtu)
 {
-return ROUND_UP((MTU_TO_MAX_FRAME_LEN(mtu) + RTE_PKTMBUF_HEADROOM),
- NETDEV_DPDK_MBUF_ALIGN);
+return ROUND_UP(MTU_TO_MAX_FRAME_LEN(mtu), NETDEV_DPDK_MBUF_ALIGN)
++ RTE_PKTMBUF_HEADROOM;
 }
 
 /* Allocates an area of 'sz' bytes from DPDK.  The memory is zero'ed.
@@ -681,6 +681,8 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu, bool 
per_port_mp)
   dev->requested_n_rxq, dev->requested_n_txq,
   RTE_CACHE_LINE_SIZE);
 
+/* The size of the mbuf's private area (i.e. area that holds OvS'
+ * dp_packet data)*/
 mbuf_priv_data_len = sizeof(struct dp_packet) -

Re: [ovs-dev] [PATCH v3] netdev-dpdk: Add mbuf HEADROOM after alignment.

2018-11-27 Thread Lam, Tiago 
Ignore, this doesn't have the required v3 changes.

On 27/11/2018 16:48, Tiago Lam wrote:
> Commit dfaf00e started using the result of dpdk_buf_size() to calculate
> the available size on each mbuf, as opposed to using the previous
> MBUF_SIZE macro. However, this was calculating the mbuf size by adding
> up the MTU with RTE_PKTMBUF_HEADROOM and only then aligning to
> NETDEV_DPDK_MBUF_ALIGN. Instead, the accounting for the
> RTE_PKTMBUF_HEADROOM should only happen after alignment, as per below.
> 
> Before alignment:
> ROUNDUP(MTU(1500) + RTE_PKTMBUF_HEADROOM(128), 1024) = 2048
> 
> After aligment:
> ROUNDUP(MTU(1500), 1024) + 128 = 2176
> 
> This might seem insignificant, however, it might have performance
> implications in DPDK, where each mbuf is expected to have 2k +
> RTE_PKTMBUF_HEADROOM of available space. This is because not only some
> NICs have course grained alignments of 1k, they will also take
> RTE_PKTMBUF_HEADROOM bytes from the overall available space in an mbuf
> when setting up their Rx requirements. Thus, only the "After alignment"
> case above would guarantee a 2k of available room, as the "Before
> alignment" would report only 1920B.
> 
> Some extra information can be found at:
> https://mails.dpdk.org/archives/dev/2018-November/119219.html
> 
> Note: This has been found by Ian Stokes while going through some
> af_packet checks.
> 
> Reported-by: Ian Stokes 
> Fixes: dfaf00e ("netdev-dpdk: fix mbuf sizing")
> Signed-off-by: Tiago Lam 
> ---
> v3:
>- Take trailer_size into account when calculating mbuf size - Ian.
> 
> v2:
>- Rebase to master 85706c3 ("ovn: Avoid tunneling for VLAN packets
>  redirected to a gateway chassis").
> 
>- Fix mbuf size calculations under Documentation/topics/dpdk/memory.rst
>  to take into account the header_size added to each mepool element (64
>  bytes) - Ian.
> ---
>  Documentation/topics/dpdk/memory.rst | 28 ++--
>  lib/netdev-dpdk.c|  6 --
>  2 files changed, 18 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/topics/dpdk/memory.rst 
> b/Documentation/topics/dpdk/memory.rst
> index c9b739f..c20dfed 100644
> --- a/Documentation/topics/dpdk/memory.rst
> +++ b/Documentation/topics/dpdk/memory.rst
> @@ -107,8 +107,8 @@ Example 1
>  
>   MTU = 1500 Bytes
>   Number of mbufs = 262144
> - Mbuf size = 2752 Bytes
> - Memory required = 262144 * 2752 = 721 MB
> + Mbuf size = 2944 Bytes
> + Memory required = 262144 * 2944 = 772 MB
>  
>  Example 2
>  +
> @@ -116,8 +116,8 @@ Example 2
>  
>   MTU = 1800 Bytes
>   Number of mbufs = 262144
> - Mbuf size = 2752 Bytes
> - Memory required = 262144 * 2752 = 721 MB
> + Mbuf size = 2944 Bytes
> + Memory required = 262144 * 2944 = 772 MB
>  
>  .. note::
>  
> @@ -130,8 +130,8 @@ Example 3
>  
>   MTU = 6000 Bytes
>   Number of mbufs = 262144
> - Mbuf size = 8000 Bytes
> - Memory required = 262144 * 8000 = 2097 MB
> + Mbuf size = 7040 Bytes
> + Memory required = 262144 * 7040 = 1845 MB
>  
>  Example 4
>  +
> @@ -139,8 +139,8 @@ Example 4
>  
>   MTU = 9000 Bytes
>   Number of mbufs = 262144
> - Mbuf size = 10048 Bytes
> - Memory required = 262144 * 10048 = 2634 MB
> + Mbuf size = 10112 Bytes
> + Memory required = 262144 * 10112 = 2651 MB
>  
>  Per Port Memory Calculations
>  
> @@ -194,8 +194,8 @@ Example 1: (1 rxq, 1 PMD, 1500 MTU)
>  
>   MTU = 1500
>   Number of mbufs = (1 * 2048) + (2 * 2048) + (1 * 32) + (16384) = 22560
> - Mbuf size = 2752 Bytes
> - Memory required = 22560 * 2752 = 62 MB
> + Mbuf size = 2944 Bytes
> + Memory required = 22560 * 2944 = 65 MB
>  
>  Example 2: (1 rxq, 2 PMD, 6000 MTU)
>  +++
> @@ -203,8 +203,8 @@ Example 2: (1 rxq, 2 PMD, 6000 MTU)
>  
>   MTU = 6000
>   Number of mbufs = (1 * 2048) + (3 * 2048) + (1 * 32) + (16384) = 24608
> - Mbuf size = 8000 Bytes
> - Memory required = 24608 * 8000 = 196 MB
> + Mbuf size = 7040 Bytes
> + Memory required = 24608 * 7040 = 173 MB
>  
>  Example 3: (2 rxq, 2 PMD, 9000 MTU)
>  +++
> @@ -212,5 +212,5 @@ Example 3: (2 rxq, 2 PMD, 9000 MTU)
>  
>   MTU = 9000
>   Number of mbufs = (2 * 2048) + (3 * 2048) + (1 * 32) + (16384) = 26656
> - Mbuf size = 10048 Bytes
> - Memory required = 26656 * 10048 = 267 MB
> + Mbuf size = 10112 Bytes
> + Memory required = 26656 * 10112 = 270 MB
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index e8618a6..a871743 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -521,8 +521,8 @@ is_dpdk_class(const struct netdev_class *class)
>  static uint32_t
>  dpdk_buf_size(int mtu)
>  {
> -return ROUND_UP((MTU_TO_MAX_FRAME_LEN(mtu) + RTE_PKTMBUF_HEADROOM),
> - NETDEV_DPDK_MBUF_ALIGN);
> +return ROUND_UP(MTU_TO_MAX_FRAME_LEN(mtu), NETDEV_DPDK_MBUF_ALIGN)
> ++ RTE_PKTMBUF_HEADROOM;
>  }
>  
>  /* Allocates an area of 'sz' bytes from DPDK.  The memory is zero'ed.
> @@ -681,6 +681,8 @@

[ovs-dev] [PATCH] ovn-sb.xml: Remove outdated paragragh which is not true any more.

2018-11-27 Thread nusiddiq 
From: Numan Siddique 

Signed-off-by: Numan Siddique 
---
 ovn/ovn-sb.xml | 5 -
 1 file changed, 5 deletions(-)

diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
index f740c9eb7..8ffef403a 100644
--- a/ovn/ovn-sb.xml
+++ b/ovn/ovn-sb.xml
@@ -1818,11 +1818,6 @@
 
   
 
-  
-The following actions will likely be useful later, but they have not
-been thought out carefully.
-  
-
   
 icmp4 { action; ... };
 
-- 
2.19.1

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

[ovs-dev] [PATCH v3] netdev-dpdk: Add mbuf HEADROOM after alignment.

2018-11-27 Thread Tiago Lam 
Commit dfaf00e started using the result of dpdk_buf_size() to calculate
the available size on each mbuf, as opposed to using the previous
MBUF_SIZE macro. However, this was calculating the mbuf size by adding
up the MTU with RTE_PKTMBUF_HEADROOM and only then aligning to
NETDEV_DPDK_MBUF_ALIGN. Instead, the accounting for the
RTE_PKTMBUF_HEADROOM should only happen after alignment, as per below.

Before alignment:
ROUNDUP(MTU(1500) + RTE_PKTMBUF_HEADROOM(128), 1024) = 2048

After aligment:
ROUNDUP(MTU(1500), 1024) + 128 = 2176

This might seem insignificant, however, it might have performance
implications in DPDK, where each mbuf is expected to have 2k +
RTE_PKTMBUF_HEADROOM of available space. This is because not only some
NICs have course grained alignments of 1k, they will also take
RTE_PKTMBUF_HEADROOM bytes from the overall available space in an mbuf
when setting up their Rx requirements. Thus, only the "After alignment"
case above would guarantee a 2k of available room, as the "Before
alignment" would report only 1920B.

Some extra information can be found at:
https://mails.dpdk.org/archives/dev/2018-November/119219.html

Note: This has been found by Ian Stokes while going through some
af_packet checks.

Reported-by: Ian Stokes 
Fixes: dfaf00e ("netdev-dpdk: fix mbuf sizing")
Signed-off-by: Tiago Lam 
---
v3:
   - Take trailer_size into account when calculating mbuf size - Ian.

v2:
   - Rebase to master 85706c3 ("ovn: Avoid tunneling for VLAN packets
 redirected to a gateway chassis").

   - Fix mbuf size calculations under Documentation/topics/dpdk/memory.rst
 to take into account the header_size added to each mepool element (64
 bytes) - Ian.
---
 Documentation/topics/dpdk/memory.rst | 28 ++--
 lib/netdev-dpdk.c|  6 --
 2 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/Documentation/topics/dpdk/memory.rst 
b/Documentation/topics/dpdk/memory.rst
index c9b739f..c20dfed 100644
--- a/Documentation/topics/dpdk/memory.rst
+++ b/Documentation/topics/dpdk/memory.rst
@@ -107,8 +107,8 @@ Example 1
 
  MTU = 1500 Bytes
  Number of mbufs = 262144
- Mbuf size = 2752 Bytes
- Memory required = 262144 * 2752 = 721 MB
+ Mbuf size = 2944 Bytes
+ Memory required = 262144 * 2944 = 772 MB
 
 Example 2
 +
@@ -116,8 +116,8 @@ Example 2
 
  MTU = 1800 Bytes
  Number of mbufs = 262144
- Mbuf size = 2752 Bytes
- Memory required = 262144 * 2752 = 721 MB
+ Mbuf size = 2944 Bytes
+ Memory required = 262144 * 2944 = 772 MB
 
 .. note::
 
@@ -130,8 +130,8 @@ Example 3
 
  MTU = 6000 Bytes
  Number of mbufs = 262144
- Mbuf size = 8000 Bytes
- Memory required = 262144 * 8000 = 2097 MB
+ Mbuf size = 7040 Bytes
+ Memory required = 262144 * 7040 = 1845 MB
 
 Example 4
 +
@@ -139,8 +139,8 @@ Example 4
 
  MTU = 9000 Bytes
  Number of mbufs = 262144
- Mbuf size = 10048 Bytes
- Memory required = 262144 * 10048 = 2634 MB
+ Mbuf size = 10112 Bytes
+ Memory required = 262144 * 10112 = 2651 MB
 
 Per Port Memory Calculations
 
@@ -194,8 +194,8 @@ Example 1: (1 rxq, 1 PMD, 1500 MTU)
 
  MTU = 1500
  Number of mbufs = (1 * 2048) + (2 * 2048) + (1 * 32) + (16384) = 22560
- Mbuf size = 2752 Bytes
- Memory required = 22560 * 2752 = 62 MB
+ Mbuf size = 2944 Bytes
+ Memory required = 22560 * 2944 = 65 MB
 
 Example 2: (1 rxq, 2 PMD, 6000 MTU)
 +++
@@ -203,8 +203,8 @@ Example 2: (1 rxq, 2 PMD, 6000 MTU)
 
  MTU = 6000
  Number of mbufs = (1 * 2048) + (3 * 2048) + (1 * 32) + (16384) = 24608
- Mbuf size = 8000 Bytes
- Memory required = 24608 * 8000 = 196 MB
+ Mbuf size = 7040 Bytes
+ Memory required = 24608 * 7040 = 173 MB
 
 Example 3: (2 rxq, 2 PMD, 9000 MTU)
 +++
@@ -212,5 +212,5 @@ Example 3: (2 rxq, 2 PMD, 9000 MTU)
 
  MTU = 9000
  Number of mbufs = (2 * 2048) + (3 * 2048) + (1 * 32) + (16384) = 26656
- Mbuf size = 10048 Bytes
- Memory required = 26656 * 10048 = 267 MB
+ Mbuf size = 10112 Bytes
+ Memory required = 26656 * 10112 = 270 MB
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index e8618a6..a871743 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -521,8 +521,8 @@ is_dpdk_class(const struct netdev_class *class)
 static uint32_t
 dpdk_buf_size(int mtu)
 {
-return ROUND_UP((MTU_TO_MAX_FRAME_LEN(mtu) + RTE_PKTMBUF_HEADROOM),
- NETDEV_DPDK_MBUF_ALIGN);
+return ROUND_UP(MTU_TO_MAX_FRAME_LEN(mtu), NETDEV_DPDK_MBUF_ALIGN)
++ RTE_PKTMBUF_HEADROOM;
 }
 
 /* Allocates an area of 'sz' bytes from DPDK.  The memory is zero'ed.
@@ -681,6 +681,8 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu, bool 
per_port_mp)
   dev->requested_n_rxq, dev->requested_n_txq,
   RTE_CACHE_LINE_SIZE);
 
+/* The size of the mbuf's private area (i.e. area that holds OvS'
+ * dp_packet data)*/
 mbuf_priv_data_len = sizeof(struct dp_packet) -

Re: [ovs-dev] [PATCH] netdev-dpdk: Add mbuf HEADROOM after alignment.

2018-11-27 Thread Lam, Tiago 
On 27/11/2018 16:10, Stokes, Ian wrote:
>> On 27/11/2018 13:57, Stokes, Ian wrote:
 Commit dfaf00e started using the result of dpdk_buf_size() to
 calculate the available size on each mbuf, as opposed to using the
 previous MBUF_SIZE macro. However, this was calculating the mbuf size
 by adding up the MTU with RTE_PKTMBUF_HEADROOM and only then aligning
 to NETDEV_DPDK_MBUF_ALIGN. Instead, the accounting for the
 RTE_PKTMBUF_HEADROOM should only happen after alignment, as per below.

 Before alignment:
 ROUNDUP(MTU(1500) + RTE_PKTMBUF_HEADROOM(128), 1024) = 2048

 After aligment:
 ROUNDUP(MTU(1500), 1024) + 128 = 2176

 This might seem insignificant, however, it might have performance
 implications in DPDK, where each mbuf is expected to have 2k +
 RTE_PKTMBUF_HEADROOM of available space. This is because not only
 some NICs have course grained alignments of 1k, they will also take
 RTE_PKTMBUF_HEADROOM bytes from the overall available space in an
 mbuf when setting up their Rx requirements. Thus, only the "After
>> alignment"
 case above would guarantee a 2k of available room, as the "Before
 alignment" would report only 1920B.

 Some extra information can be found at:
 https://mails.dpdk.org/archives/dev/2018-November/119219.html

 Note: This has been found by Ian Stokes while going through some
 af_packet checks.

>>>
>>> Hi Tiago,, thanks for this, just a query below.
>>>
 Reported-by: Ian Stokes 
 Fixes: dfaf00e ("netdev-dpdk: fix mbuf sizing")
 Signed-off-by: Tiago Lam 
 ---
  Documentation/topics/dpdk/memory.rst | 20 ++--
  lib/netdev-dpdk.c|  6 --
  2 files changed, 14 insertions(+), 12 deletions(-)

 diff --git a/Documentation/topics/dpdk/memory.rst
 b/Documentation/topics/dpdk/memory.rst
 index c9b739f..3c4ee17 100644
 --- a/Documentation/topics/dpdk/memory.rst
 +++ b/Documentation/topics/dpdk/memory.rst
 @@ -107,8 +107,8 @@ Example 1

   MTU = 1500 Bytes
   Number of mbufs = 262144
 - Mbuf size = 2752 Bytes
 - Memory required = 262144 * 2752 = 721 MB
 + Mbuf size = 2880 Bytes
 + Memory required = 262144 * 2880 = 755 MB
>>>
>>> These measurements don't deem to take the header and trailer into
>> account for total size when calculating the memory requirements? Is there
>> any particular reason?
>>>
>>> total_elt_sz = mp->header_size + mp->elt_size + mp->trailer_size;
>>>
>>> I would expect above to be 262144 * 3008 = 788 MB.
>>
>> Thanks for looking into it, Ian.
>>
>> I hadn't considered that.
>>
>> But I guess you're right, technically, since that will end up being the
>> total size of each mempool element. However, the size of each mbuf is
>> still the 2880B above.
>>
>> Looking into commit 31154f95 (before the first change to this file was
>> applied), I can see that the size of each mbuf would be 2944B (for a 1500B
>> MTU), where each mempool element would have a size of 3008B (the extra 64B
>> is the mp->header_size above). And we are using the 3008B instead of the
>> 2944B as the mbuf size. Was this on purpose to reflect the total memory
>> required?
> 
> Yes, this is on purpose to account for the total memory requirements for a 
> given deployment as memory for the header would also have to be provisioned 
> for.
> 
>>
>> Just wondering though, I can add the same logic anyway, which would change
>> the values to 2880B + 64B = 2944B.
> 
> I think above should be 3008 again, looking at the v1 of this patch it would 
> break down as follows
> 
> total_elt_sz = mp->header_size + mp->elt_size + mp->trailer_size;
> 3008 = 64 + 2880 + 64
> 
> I would think the trailer should be accounted for as well as the header.
> 
> Ian

Fair enough, I'll send v3.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] netdev-dpdk: Add mbuf HEADROOM after alignment.

2018-11-27 Thread Stokes, Ian 
> On 27/11/2018 13:57, Stokes, Ian wrote:
> >> Commit dfaf00e started using the result of dpdk_buf_size() to
> >> calculate the available size on each mbuf, as opposed to using the
> >> previous MBUF_SIZE macro. However, this was calculating the mbuf size
> >> by adding up the MTU with RTE_PKTMBUF_HEADROOM and only then aligning
> >> to NETDEV_DPDK_MBUF_ALIGN. Instead, the accounting for the
> >> RTE_PKTMBUF_HEADROOM should only happen after alignment, as per below.
> >>
> >> Before alignment:
> >> ROUNDUP(MTU(1500) + RTE_PKTMBUF_HEADROOM(128), 1024) = 2048
> >>
> >> After aligment:
> >> ROUNDUP(MTU(1500), 1024) + 128 = 2176
> >>
> >> This might seem insignificant, however, it might have performance
> >> implications in DPDK, where each mbuf is expected to have 2k +
> >> RTE_PKTMBUF_HEADROOM of available space. This is because not only
> >> some NICs have course grained alignments of 1k, they will also take
> >> RTE_PKTMBUF_HEADROOM bytes from the overall available space in an
> >> mbuf when setting up their Rx requirements. Thus, only the "After
> alignment"
> >> case above would guarantee a 2k of available room, as the "Before
> >> alignment" would report only 1920B.
> >>
> >> Some extra information can be found at:
> >> https://mails.dpdk.org/archives/dev/2018-November/119219.html
> >>
> >> Note: This has been found by Ian Stokes while going through some
> >> af_packet checks.
> >>
> >
> > Hi Tiago,, thanks for this, just a query below.
> >
> >> Reported-by: Ian Stokes 
> >> Fixes: dfaf00e ("netdev-dpdk: fix mbuf sizing")
> >> Signed-off-by: Tiago Lam 
> >> ---
> >>  Documentation/topics/dpdk/memory.rst | 20 ++--
> >>  lib/netdev-dpdk.c|  6 --
> >>  2 files changed, 14 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/Documentation/topics/dpdk/memory.rst
> >> b/Documentation/topics/dpdk/memory.rst
> >> index c9b739f..3c4ee17 100644
> >> --- a/Documentation/topics/dpdk/memory.rst
> >> +++ b/Documentation/topics/dpdk/memory.rst
> >> @@ -107,8 +107,8 @@ Example 1
> >>
> >>   MTU = 1500 Bytes
> >>   Number of mbufs = 262144
> >> - Mbuf size = 2752 Bytes
> >> - Memory required = 262144 * 2752 = 721 MB
> >> + Mbuf size = 2880 Bytes
> >> + Memory required = 262144 * 2880 = 755 MB
> >
> > These measurements don't deem to take the header and trailer into
> account for total size when calculating the memory requirements? Is there
> any particular reason?
> >
> > total_elt_sz = mp->header_size + mp->elt_size + mp->trailer_size;
> >
> > I would expect above to be 262144 * 3008 = 788 MB.
> 
> Thanks for looking into it, Ian.
> 
> I hadn't considered that.
> 
> But I guess you're right, technically, since that will end up being the
> total size of each mempool element. However, the size of each mbuf is
> still the 2880B above.
> 
> Looking into commit 31154f95 (before the first change to this file was
> applied), I can see that the size of each mbuf would be 2944B (for a 1500B
> MTU), where each mempool element would have a size of 3008B (the extra 64B
> is the mp->header_size above). And we are using the 3008B instead of the
> 2944B as the mbuf size. Was this on purpose to reflect the total memory
> required?

Yes, this is on purpose to account for the total memory requirements for a 
given deployment as memory for the header would also have to be provisioned for.

> 
> Just wondering though, I can add the same logic anyway, which would change
> the values to 2880B + 64B = 2944B.

I think above should be 3008 again, looking at the v1 of this patch it would 
break down as follows

total_elt_sz = mp->header_size + mp->elt_size + mp->trailer_size;
3008 = 64 + 2880 + 64

I would think the trailer should be accounted for as well as the header.

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

[ovs-dev] [PATCH v2] netdev-dpdk: Add mbuf HEADROOM after alignment.

2018-11-27 Thread Tiago Lam 
Commit dfaf00e started using the result of dpdk_buf_size() to calculate
the available size on each mbuf, as opposed to using the previous
MBUF_SIZE macro. However, this was calculating the mbuf size by adding
up the MTU with RTE_PKTMBUF_HEADROOM and only then aligning to
NETDEV_DPDK_MBUF_ALIGN. Instead, the accounting for the
RTE_PKTMBUF_HEADROOM should only happen after alignment, as per below.

Before alignment:
ROUNDUP(MTU(1500) + RTE_PKTMBUF_HEADROOM(128), 1024) = 2048

After aligment:
ROUNDUP(MTU(1500), 1024) + 128 = 2176

This might seem insignificant, however, it might have performance
implications in DPDK, where each mbuf is expected to have 2k +
RTE_PKTMBUF_HEADROOM of available space. This is because not only some
NICs have course grained alignments of 1k, they will also take
RTE_PKTMBUF_HEADROOM bytes from the overall available space in an mbuf
when setting up their Rx requirements. Thus, only the "After alignment"
case above would guarantee a 2k of available room, as the "Before
alignment" would report only 1920B.

Some extra information can be found at:
https://mails.dpdk.org/archives/dev/2018-November/119219.html

Note: This has been found by Ian Stokes while going through some
af_packet checks.

Reported-by: Ian Stokes 
Fixes: dfaf00e ("netdev-dpdk: fix mbuf sizing")
Signed-off-by: Tiago Lam 
---
v2:
   - Rebase to master 85706c3 ("ovn: Avoid tunneling for VLAN packets
 redirected to a gateway chassis").

   - Fix mbuf size calculations under Documentation/topics/dpdk/memory.rst
 to take into account the header_size added to each mepool element (64
 bytes) - Ian.
---


 Documentation/topics/dpdk/memory.rst | 28 ++--
 lib/netdev-dpdk.c|  6 --
 2 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/Documentation/topics/dpdk/memory.rst 
b/Documentation/topics/dpdk/memory.rst
index c9b739f..c20dfed 100644
--- a/Documentation/topics/dpdk/memory.rst
+++ b/Documentation/topics/dpdk/memory.rst
@@ -107,8 +107,8 @@ Example 1
 
  MTU = 1500 Bytes
  Number of mbufs = 262144
- Mbuf size = 2752 Bytes
- Memory required = 262144 * 2752 = 721 MB
+ Mbuf size = 2944 Bytes
+ Memory required = 262144 * 2944 = 772 MB
 
 Example 2
 +
@@ -116,8 +116,8 @@ Example 2
 
  MTU = 1800 Bytes
  Number of mbufs = 262144
- Mbuf size = 2752 Bytes
- Memory required = 262144 * 2752 = 721 MB
+ Mbuf size = 2944 Bytes
+ Memory required = 262144 * 2944 = 772 MB
 
 .. note::
 
@@ -130,8 +130,8 @@ Example 3
 
  MTU = 6000 Bytes
  Number of mbufs = 262144
- Mbuf size = 8000 Bytes
- Memory required = 262144 * 8000 = 2097 MB
+ Mbuf size = 7040 Bytes
+ Memory required = 262144 * 7040 = 1845 MB
 
 Example 4
 +
@@ -139,8 +139,8 @@ Example 4
 
  MTU = 9000 Bytes
  Number of mbufs = 262144
- Mbuf size = 10048 Bytes
- Memory required = 262144 * 10048 = 2634 MB
+ Mbuf size = 10112 Bytes
+ Memory required = 262144 * 10112 = 2651 MB
 
 Per Port Memory Calculations
 
@@ -194,8 +194,8 @@ Example 1: (1 rxq, 1 PMD, 1500 MTU)
 
  MTU = 1500
  Number of mbufs = (1 * 2048) + (2 * 2048) + (1 * 32) + (16384) = 22560
- Mbuf size = 2752 Bytes
- Memory required = 22560 * 2752 = 62 MB
+ Mbuf size = 2944 Bytes
+ Memory required = 22560 * 2944 = 65 MB
 
 Example 2: (1 rxq, 2 PMD, 6000 MTU)
 +++
@@ -203,8 +203,8 @@ Example 2: (1 rxq, 2 PMD, 6000 MTU)
 
  MTU = 6000
  Number of mbufs = (1 * 2048) + (3 * 2048) + (1 * 32) + (16384) = 24608
- Mbuf size = 8000 Bytes
- Memory required = 24608 * 8000 = 196 MB
+ Mbuf size = 7040 Bytes
+ Memory required = 24608 * 7040 = 173 MB
 
 Example 3: (2 rxq, 2 PMD, 9000 MTU)
 +++
@@ -212,5 +212,5 @@ Example 3: (2 rxq, 2 PMD, 9000 MTU)
 
  MTU = 9000
  Number of mbufs = (2 * 2048) + (3 * 2048) + (1 * 32) + (16384) = 26656
- Mbuf size = 10048 Bytes
- Memory required = 26656 * 10048 = 267 MB
+ Mbuf size = 10112 Bytes
+ Memory required = 26656 * 10112 = 270 MB
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index e8618a6..a871743 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -521,8 +521,8 @@ is_dpdk_class(const struct netdev_class *class)
 static uint32_t
 dpdk_buf_size(int mtu)
 {
-return ROUND_UP((MTU_TO_MAX_FRAME_LEN(mtu) + RTE_PKTMBUF_HEADROOM),
- NETDEV_DPDK_MBUF_ALIGN);
+return ROUND_UP(MTU_TO_MAX_FRAME_LEN(mtu), NETDEV_DPDK_MBUF_ALIGN)
++ RTE_PKTMBUF_HEADROOM;
 }
 
 /* Allocates an area of 'sz' bytes from DPDK.  The memory is zero'ed.
@@ -681,6 +681,8 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu, bool 
per_port_mp)
   dev->requested_n_rxq, dev->requested_n_txq,
   RTE_CACHE_LINE_SIZE);
 
+/* The size of the mbuf's private area (i.e. area that holds OvS'
+ * dp_packet data)*/
 mbuf_priv_data_len = sizeof(struct dp_packet) -
  sizeof(struct rte_mbuf);
 /* The size of the entire dp_packet. */
--

Re: [ovs-dev] [PATCH] netdev-dpdk: Add mbuf HEADROOM after alignment.

2018-11-27 Thread Lam, Tiago 
On 27/11/2018 13:57, Stokes, Ian wrote:
>> Commit dfaf00e started using the result of dpdk_buf_size() to calculate
>> the available size on each mbuf, as opposed to using the previous
>> MBUF_SIZE macro. However, this was calculating the mbuf size by adding up
>> the MTU with RTE_PKTMBUF_HEADROOM and only then aligning to
>> NETDEV_DPDK_MBUF_ALIGN. Instead, the accounting for the
>> RTE_PKTMBUF_HEADROOM should only happen after alignment, as per below.
>>
>> Before alignment:
>> ROUNDUP(MTU(1500) + RTE_PKTMBUF_HEADROOM(128), 1024) = 2048
>>
>> After aligment:
>> ROUNDUP(MTU(1500), 1024) + 128 = 2176
>>
>> This might seem insignificant, however, it might have performance
>> implications in DPDK, where each mbuf is expected to have 2k +
>> RTE_PKTMBUF_HEADROOM of available space. This is because not only some
>> NICs have course grained alignments of 1k, they will also take
>> RTE_PKTMBUF_HEADROOM bytes from the overall available space in an mbuf
>> when setting up their Rx requirements. Thus, only the "After alignment"
>> case above would guarantee a 2k of available room, as the "Before
>> alignment" would report only 1920B.
>>
>> Some extra information can be found at:
>> https://mails.dpdk.org/archives/dev/2018-November/119219.html
>>
>> Note: This has been found by Ian Stokes while going through some af_packet
>> checks.
>>
> 
> Hi Tiago,, thanks for this, just a query below.
> 
>> Reported-by: Ian Stokes 
>> Fixes: dfaf00e ("netdev-dpdk: fix mbuf sizing")
>> Signed-off-by: Tiago Lam 
>> ---
>>  Documentation/topics/dpdk/memory.rst | 20 ++--
>>  lib/netdev-dpdk.c|  6 --
>>  2 files changed, 14 insertions(+), 12 deletions(-)
>>
>> diff --git a/Documentation/topics/dpdk/memory.rst
>> b/Documentation/topics/dpdk/memory.rst
>> index c9b739f..3c4ee17 100644
>> --- a/Documentation/topics/dpdk/memory.rst
>> +++ b/Documentation/topics/dpdk/memory.rst
>> @@ -107,8 +107,8 @@ Example 1
>>
>>   MTU = 1500 Bytes
>>   Number of mbufs = 262144
>> - Mbuf size = 2752 Bytes
>> - Memory required = 262144 * 2752 = 721 MB
>> + Mbuf size = 2880 Bytes
>> + Memory required = 262144 * 2880 = 755 MB
> 
> These measurements don't deem to take the header and trailer into account for 
> total size when calculating the memory requirements? Is there any particular 
> reason? 
> 
> total_elt_sz = mp->header_size + mp->elt_size + mp->trailer_size;
> 
> I would expect above to be 262144 * 3008 = 788 MB.

Thanks for looking into it, Ian.

I hadn't considered that.

But I guess you're right, technically, since that will end up being the
total size of each mempool element. However, the size of each mbuf is
still the 2880B above.

Looking into commit 31154f95 (before the first change to this file was
applied), I can see that the size of each mbuf would be 2944B (for a
1500B MTU), where each mempool element would have a size of 3008B (the
extra 64B is the mp->header_size above). And we are using the 3008B
instead of the 2944B as the mbuf size. Was this on purpose to reflect
the total memory required?

Just wondering though, I can add the same logic anyway, which would
change the values to 2880B + 64B = 2944B.

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

[ovs-dev] [PATCH] openvswitch: fix spelling mistake "execeeds" -> "exceeds"

2018-11-27 Thread Colin King 
From: Colin Ian King 

There is a spelling mistake in a net_warn_ratelimited message, fix this.

Signed-off-by: Colin Ian King 
---
 net/openvswitch/conntrack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index a4660c48ff01..cd94f925495a 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -1166,7 +1166,7 @@ static int ovs_ct_commit(struct net *net, struct 
sw_flow_key *key,
>tuplehash[IP_CT_DIR_ORIGINAL].tuple);
if (err) {
net_warn_ratelimited("openvswitch: zone: %u "
-   "execeeds conntrack limit\n",
+   "exceeds conntrack limit\n",
info->zone.id);
return err;
}
-- 
2.19.1

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

Re: [ovs-dev] [PATCH] netdev-dpdk: Add mbuf HEADROOM after alignment.

2018-11-27 Thread Stokes, Ian 
> Commit dfaf00e started using the result of dpdk_buf_size() to calculate
> the available size on each mbuf, as opposed to using the previous
> MBUF_SIZE macro. However, this was calculating the mbuf size by adding up
> the MTU with RTE_PKTMBUF_HEADROOM and only then aligning to
> NETDEV_DPDK_MBUF_ALIGN. Instead, the accounting for the
> RTE_PKTMBUF_HEADROOM should only happen after alignment, as per below.
> 
> Before alignment:
> ROUNDUP(MTU(1500) + RTE_PKTMBUF_HEADROOM(128), 1024) = 2048
> 
> After aligment:
> ROUNDUP(MTU(1500), 1024) + 128 = 2176
> 
> This might seem insignificant, however, it might have performance
> implications in DPDK, where each mbuf is expected to have 2k +
> RTE_PKTMBUF_HEADROOM of available space. This is because not only some
> NICs have course grained alignments of 1k, they will also take
> RTE_PKTMBUF_HEADROOM bytes from the overall available space in an mbuf
> when setting up their Rx requirements. Thus, only the "After alignment"
> case above would guarantee a 2k of available room, as the "Before
> alignment" would report only 1920B.
> 
> Some extra information can be found at:
> https://mails.dpdk.org/archives/dev/2018-November/119219.html
> 
> Note: This has been found by Ian Stokes while going through some af_packet
> checks.
> 

Hi Tiago,, thanks for this, just a query below.

> Reported-by: Ian Stokes 
> Fixes: dfaf00e ("netdev-dpdk: fix mbuf sizing")
> Signed-off-by: Tiago Lam 
> ---
>  Documentation/topics/dpdk/memory.rst | 20 ++--
>  lib/netdev-dpdk.c|  6 --
>  2 files changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/topics/dpdk/memory.rst
> b/Documentation/topics/dpdk/memory.rst
> index c9b739f..3c4ee17 100644
> --- a/Documentation/topics/dpdk/memory.rst
> +++ b/Documentation/topics/dpdk/memory.rst
> @@ -107,8 +107,8 @@ Example 1
> 
>   MTU = 1500 Bytes
>   Number of mbufs = 262144
> - Mbuf size = 2752 Bytes
> - Memory required = 262144 * 2752 = 721 MB
> + Mbuf size = 2880 Bytes
> + Memory required = 262144 * 2880 = 755 MB

These measurements don't deem to take the header and trailer into account for 
total size when calculating the memory requirements? Is there any particular 
reason? 

total_elt_sz = mp->header_size + mp->elt_size + mp->trailer_size;

I would expect above to be 262144 * 3008 = 788 MB.

Ian
> 
>  Example 2
>  +
> @@ -116,8 +116,8 @@ Example 2
> 
>   MTU = 1800 Bytes
>   Number of mbufs = 262144
> - Mbuf size = 2752 Bytes
> - Memory required = 262144 * 2752 = 721 MB
> + Mbuf size = 2880 Bytes
> + Memory required = 262144 * 2880 = 755 MB
> 
>  .. note::
> 
> @@ -130,8 +130,8 @@ Example 3
> 
>   MTU = 6000 Bytes
>   Number of mbufs = 262144
> - Mbuf size = 8000 Bytes
> - Memory required = 262144 * 8000 = 2097 MB
> + Mbuf size = 6976 Bytes
> + Memory required = 262144 * 6976 = 1829 MB
> 
>  Example 4
>  +
> @@ -194,8 +194,8 @@ Example 1: (1 rxq, 1 PMD, 1500 MTU)
> 
>   MTU = 1500
>   Number of mbufs = (1 * 2048) + (2 * 2048) + (1 * 32) + (16384) = 22560
> - Mbuf size = 2752 Bytes
> - Memory required = 22560 * 2752 = 62 MB
> + Mbuf size = 2880 Bytes
> + Memory required = 22560 * 2880 = 65 MB
> 
>  Example 2: (1 rxq, 2 PMD, 6000 MTU)
>  +++
> @@ -203,8 +203,8 @@ Example 2: (1 rxq, 2 PMD, 6000 MTU)
> 
>   MTU = 6000
>   Number of mbufs = (1 * 2048) + (3 * 2048) + (1 * 32) + (16384) = 24608
> - Mbuf size = 8000 Bytes
> - Memory required = 24608 * 8000 = 196 MB
> + Mbuf size = 6976 Bytes
> + Memory required = 24608 * 6976 = 171 MB
> 
>  Example 3: (2 rxq, 2 PMD, 9000 MTU)
>  +++
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index e8618a6..a871743
> 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -521,8 +521,8 @@ is_dpdk_class(const struct netdev_class *class)
> static uint32_t  dpdk_buf_size(int mtu)  {
> -return ROUND_UP((MTU_TO_MAX_FRAME_LEN(mtu) + RTE_PKTMBUF_HEADROOM),
> - NETDEV_DPDK_MBUF_ALIGN);
> +return ROUND_UP(MTU_TO_MAX_FRAME_LEN(mtu), NETDEV_DPDK_MBUF_ALIGN)
> ++ RTE_PKTMBUF_HEADROOM;
>  }
> 
>  /* Allocates an area of 'sz' bytes from DPDK.  The memory is zero'ed.
> @@ -681,6 +681,8 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu, bool
> per_port_mp)
>dev->requested_n_rxq, dev->requested_n_txq,
>RTE_CACHE_LINE_SIZE);
> 
> +/* The size of the mbuf's private area (i.e. area that holds OvS'
> + * dp_packet data)*/
>  mbuf_priv_data_len = sizeof(struct dp_packet) -
>   sizeof(struct rte_mbuf);
>  /* The size of the entire dp_packet. */
> --
> 2.7.4

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

[ovs-dev] payment copy

2018-11-27 Thread info 
 
 
 Dear d...@openvswitch.org
 Following the instruction of our client your customer. Your latest swift copy 
is attached.

Please download and open attachment to view payment copy and payee details.

 Regards, 
 Customer Service
Mashreq 
 
This email was sent to d...@openvswitch.org
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev