LOL, I was thinking pahole was a person. ☺

>>The cacheline boundaries are interesting, but not enforced by the structure alignment.
>Not sure what you mean here?
The struct _Flow is not marked with an alignment attribute to align it to 64 byte boundaries, so the structure is not required start of a cacheline boundary. That is likely a good thing, since with the alignment 64, an array of these would need to pad the 5th cacheline by 24 bytes to align the next struct to the next cacheline. If it was aligned to cachelines, then the extra padding added by my patch wouldn’t matter.

I will look for pahole, I have wanted that type of tool for a long time.

Regards,
-Ken

From: Victor Julien [mailto:notifications@github.com]
Sent: Tuesday, September 10, 2013 11:13 AM
To: inliniac/suricata
Cc: Kenneth Steele
Subject: Re: [suricata] Tile atomic (#534)


In src/flow.h:

> @@ -290,7 +290,7 @@

>       *  On receiving a packet the counter is incremented while the flow

>       *  bucked is locked, which is also the case on timeout pruning.

>       */

> -    SC_ATOMIC_DECLARE(unsigned short, use_cnt);

> +    SC_ATOMIC_DECLARE(unsigned int, use_cnt);
On 09/10/2013 05:10 PM, Ken Steele wrote: In src/flow.h: > @@ -290,7 +290,7 @@ > * On receiving a packet the counter is incremented while the flow > * bucked is locked, which is also the case on timeout pruning. > */ > - SC_ATOMIC_DECLARE(unsigned short, use_cnt); > + SC_ATOMIC_DECLARE(unsigned int, use_cnt); pahole is correct, I missed that vlanid was an array of two values. Are these comments generated by hand or programmatically?
They are created by pahole. I ran it as: pahole -C Flow_ src/suricata
The cacheline boundaries are interesting, but not enforced by the structure alignment.
Not sure what you mean here?

—
Reply to this email directly or view it on GitHub<https://github.com/inliniac/suricata/pull/534/files#r6268499>.