By reordering the data elements in dpif_upcall structure, pad bytes can
be reduced and also a cache line. Also dp_packet should be the first
member of the structure because rte_mbuf, the first member of dp_packet
should be aligned atleast on a 64-byte boundary.

Before: structure size:768, holes:1, sum padbytes:60, cachelines:12
After: structure size:704, holes:1, sum padbytes:4, cachelines:11

Signed-off-by: Bhanuprakash Bodireddy <bhanuprakash.bodire...@intel.com>
Co-authored-by: Antonio Fischetti <antonio.fische...@intel.com>
Signed-off-by: Antonio Fischetti <antonio.fische...@intel.com>
Acked-by: Jarno Rajahalme <ja...@ovn.org>
---
 lib/dpif.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/dpif.h b/lib/dpif.h
index 8a68d5d..cade046 100644
--- a/lib/dpif.h
+++ b/lib/dpif.h
@@ -780,8 +780,11 @@ const char *dpif_upcall_type_to_string(enum 
dpif_upcall_type);
  */
 struct dpif_upcall {
     /* All types. */
+    struct dp_packet packet;    /* Packet data,'dp_packet' should be the first
+                                  member to avoid a hole. This is because
+                                  'rte_mbuf' in dp_packet is aligned atleast
+                                  on a 64-byte boundary */
     enum dpif_upcall_type type;
-    struct dp_packet packet;       /* Packet data. */
     struct nlattr *key;         /* Flow key. */
     size_t key_len;             /* Length of 'key' in bytes. */
     ovs_u128 ufid;              /* Unique flow identifier for 'key'. */
-- 
2.4.11

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

Reply via email to