Patchwork [net-next,17/17] tcp: get rid of two unnecessary u16s in TCP skb flags copying

login
register
mail settings
Submitter Ilpo Järvinen
Date Feb. 28, 2009, 2:44 p.m.
Message ID <12358322832837-git-send-email-ilpo.jarvinen@helsinki.fi>
Download mbox | patch
Permalink /patch/23893/
State Accepted
Delegated to: David Miller
Headers show

Comments

Ilpo Järvinen - Feb. 28, 2009, 2:44 p.m.
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(-)
Andi Kleen - March 1, 2009, 2:39 a.m.
"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
David Miller - March 1, 2009, 3:08 a.m.
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
Andi Kleen - March 1, 2009, 9:44 p.m.
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
David Miller - March 2, 2009, 11:03 a.m.
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

Patch

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)