Typically when 16bit is not nice, 8bit isn't nice either.
For general flags the most save in terms of uniform performance
is "int"

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.
--

[ message continues ]

Yes old Alpha is the only one I know, although I don't claim to know every 
weirdness of every embedded CPU out there.


x86 normally[1] doesn't care, but it also doesn't save anything normally
for a on stack (or in register) variable because there's typically
padding anyways.

[1] there are some issues on older Intel CPUs with partial register
stall in a few cases.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.
--

[ message continues ]

From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>

I guess these fields were one day 16-bit in the struct but
nowadays they're just using 8 bits anyway.

This is just a precaution, didn't result any change in my
case but who knows what all those varying gcc versions &
options do. I've been told that 16-bit is not so nice with
some cpus.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
 net/ipv4/tcp_output.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index d5c7245..274110e 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -766,7 +766,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
 	struct sk_buff *buff;
 	int nsize, old_factor;
 	int nlen;
-	u16 flags;
+	u8 flags;
 
 	BUG_ON(len > skb->len);
 
@@ -1281,7 +1281,7 @@ static int tso_fragment(struct sock *sk, struct sk_buff *skb, unsigned int len,
 {
 	struct sk_buff *buff;
 	int nlen = skb->len - len;
-	u16 flags;
+	u8 flags;
 
 	/* All of a TSO frame must be composed of paged data.  */
 	if (skb->len != skb->data_len)
-- 
1.5.6.5

--

[ message continues ]

From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>

Applied.
--

[ message continues ]

From: Andi Kleen <andi@firstfloor.org>

It's really only the truly ancient alpha cpus where this is
a measurable issue.  Those chips only have 32-bit loads
and stores, so ever sub-32-bit access involves a 32-bit
load/store and a bunch of byte extraction instructions.

I don't think it's a relevant concern today.  Especially
on x86 if that's why you are alluding to Andi.

--

[ message continues ]