| Message ID | 12358322832837-git-send-email-ilpo.jarvinen@helsinki.fi |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> writes: > 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. 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
From: Andi Kleen <andi@firstfloor.org> Date: Sun, 01 Mar 2009 03:39:02 +0100 > "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> writes: > > > 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. > > Typically when 16bit is not nice, 8bit isn't nice either. > For general flags the most save in terms of uniform performance > is "int" 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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Feb 28, 2009 at 07:08:45PM -0800, David Miller wrote: > From: Andi Kleen <andi@firstfloor.org> > Date: Sun, 01 Mar 2009 03:39:02 +0100 > > > "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> writes: > > > > > 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. > > > > Typically when 16bit is not nice, 8bit isn't nice either. > > For general flags the most save in terms of uniform performance > > is "int" > > 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. Yes old Alpha is the only one I know, although I don't claim to know every weirdness of every embedded CPU out there. My point was merely that 16bit is not in any way better than 8 bit. > > I don't think it's a relevant concern today. Especially > on x86 if that's why you are alluding to Andi. 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
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> Date: Sat, 28 Feb 2009 16:44:42 +0200 > 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> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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)