Thread (1 message) 1 message, 1 author, 2014-03-09

Re: [PATCH net-next v4 1/4] ieee802154: add generic header handling routines

From: David Miller <hidden>
Date: 2014-03-09 22:49:17

From: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
Date: Sun, 09 Mar 2014 17:59:03 +0000
On Tue, 2014-03-04 at 17:20 -0500, David Miller wrote:
quoted
From: "Phoebe Buckheister" <redacted>
Date: Tue, 4 Mar 2014 23:16:31 +0100
quoted
I see some value in being able to memcpy() to/from those fields directly
when building/reading headers, but I also think that not having to do
endianness conversion everywhere for a struct that cannot ever be a valid
header as is outweighs this.
Why have an intermediate copy when that's not necessary at all?  It
seems like pure overhead to be.

Furthermore, cpu's have byte-shifting load and store instructions
which will be used if you make use of the 'p' versions of the endian
swap functions, such as cpu_to_le16p().

So it's going to cost basically nothing.
The real frame headers don't have naturally aligned fields, so if the
structures are to mirror them they would need to be __packed.  I'm sure
you realise what that does for performance.
Ok.  There is always the option of recording the translated values
in the SKB control block like TCP does for sequence numbers and
such.

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help