That's the only field in flows with different storage sizes depending
on the architecture: it's usually 4-byte wide on 32-bit architectures,
except for arc and x32 where it's 8 bytes, and 8-byte wide on 64-bit
machines.
By keeping flow entries the same size across architectures, we avoid
having to expand or shrink table entries upon migration.
Signed-off-by: Stefano Brivio
---
icmp_flow.h | 6 +++++-
udp_flow.h | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/icmp_flow.h b/icmp_flow.h
index fb93801..da7e255 100644
--- a/icmp_flow.h
+++ b/icmp_flow.h
@@ -13,6 +13,7 @@
* @seq: Last sequence number sent to tap, host order, -1: not sent yet
* @sock: "ping" socket
* @ts: Last associated activity from tap, seconds
+ * @ts_storage: Pad @ts to 64-bit storage to keep state migration sane
*/
struct icmp_ping_flow {
/* Must be first element */
@@ -20,7 +21,10 @@ struct icmp_ping_flow {
int seq;
int sock;
- time_t ts;
+ union {
+ time_t ts;
+ uint64_t ts_storage;
+ };
};
bool icmp_ping_timer(const struct ctx *c, const struct icmp_ping_flow *pingf,
diff --git a/udp_flow.h b/udp_flow.h
index 9a1b059..9cb79a0 100644
--- a/udp_flow.h
+++ b/udp_flow.h
@@ -12,6 +12,7 @@
* @f: Generic flow information
* @closed: Flow is already closed
* @ts: Activity timestamp
+ * @ts_storage: Pad @ts to 64-bit storage to keep state migration sane
* @s: Socket fd (or -1) for each side of the flow
*/
struct udp_flow {
@@ -19,7 +20,10 @@ struct udp_flow {
struct flow_common f;
bool closed :1;
- time_t ts;
+ union {
+ time_t ts;
+ uint64_t ts_storage;
+ };
int s[SIDES];
};
--
2.43.0