To accommodate wifi, Sebastien recently bumped the size of the tag buffer by one byte:

diff -r fc5b7dc0a98b src/network/model/packet-tag-list.h
--- a/src/network/model/packet-tag-list.h	Fri Sep 04 22:18:00 2015 +0200
+++ b/src/network/model/packet-tag-list.h	Thu Mar 31 13:59:55 2016 -0700
@@ -158,7 +158,7 @@
      */
     enum TagData_e
     {
-      MAX_SIZE = 20           /**< Size of serialization buffer #data */
+      MAX_SIZE = 21           /**< Size of serialization buffer #data */
   };
 
     uint8_t data[MAX_SIZE];   /**< Serialization buffer */


---

at least, the documentation is out of sync with this, so at a minimum it should be updated, but in discussions on bug 2308, questions were raised as to what was a reasonable value.

There is this code comment:

     * \internal
     * Ideally, TagData would be 32 bytes in size, so they require
     * no padding on 64-bit architectures.  (The architecture
     * affects the size because of the \c #next pointer.)
     * This would leave 18 bytes for \c #data.  However,
     * ns3:Ipv6PacketInfoTag needs 19 bytes!  The current
     * implementation allows 20 bytes, which gives TagData
     * a size of 30 bytes on 32-byte machines (which gets
     * padded with 2 bytes), and 34 bytes on 64-bit machines, which
     * gets padded to 40 bytes.

What is the implication of 21 or 22 byte limits on these two different architectures?

Or should we instead change the implementation according to Alex's proposal in bug 1383, and remove these limits?