I tried to group recovery related fields nearby (non-CA_Open related
variables, to be more accurate) so that one to three cachelines would
not be necessary in CA_Open. These are now contiguously deployed:
struct sk_buff_head out_of_order_queue; /* 1968 80 */
/* --- cacheline 32 boundary (2048 bytes) --- */
struct tcp_sack_block duplicate_sack[1]; /* 2048 8 */
struct tcp_sack_block selective_acks[4]; /* 2056 32 */
struct tcp_sack_block recv_sack_cache[4]; /* 2088 32 */
/* --- cacheline 33 boundary (2112 bytes) was 8 bytes ago --- */
struct sk_buff * highest_sack; /* 2120 8 */
int lost_cnt_hint; /* 2128 4 */
int retransmit_cnt_hint; /* 2132 4 */
u32 lost_retrans_low; /* 2136 4 */
u8 reordering; /* 2140 1 */
u8 keepalive_probes; /* 2141 1 */
/* XXX 2 bytes hole, try to pack */
u32 prior_ssthresh; /* 2144 4 */
u32 high_seq; /* 2148 4 */
u32 retrans_stamp; /* 2152 4 */
u32 undo_marker; /* 2156 4 */
int undo_retrans; /* 2160 4 */
u32 total_retrans; /* 2164 4 */
...and they're then followed by URG slowpath & keepalive related
variables.
Head of the out_of_order_queue always needed for empty checks, if
that's empty (and TCP is in CA_Open), following ~200 bytes (in 64-bit)
shouldn't be necessary for anything. If only OFO queue exists but TCP
is in CA_Open, selective_acks (and possibly duplicate_sack) are
necessary besides the out_of_order_queue but the rest of the block
again shouldn't be (ie., the other direction had losses).
As the cacheline boundaries depend on many factors in the preceeding
stuff, trying to align considering them doesn't make too much sense.
Commented one ordering hazard.
There are number of low utilized u8/16s that could be combined get 2
bytes less in total so that the hole could be made to vanish (includes
at least ecn_flags, urg_data, urg_mode, frto_counter, nonagle).
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Acked-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
b79eeeb9e4