Pierre Ossman a écrit :
On Mon, 22 Oct 2007 02:05:38 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
From: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 10:42:08 +0200
This seems like a rather evil layering violation.
This has a 10+ year precedence and it's why
On Mon, 22 Oct 2007 02:05:38 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Pierre Ossman <[EMAIL PROTECTED]>
> Date: Mon, 22 Oct 2007 10:42:08 +0200
>
> > This seems like a rather evil layering violation.
>
> This has a 10+ year precedence and it's why the Linux networking stack
>
From: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 10:42:08 +0200
> This seems like a rather evil layering violation.
This has a 10+ year precedence and it's why the Linux networking stack
is so fast. If you read any other driver you would have seen the
skb_reserve() call every one o
On Mon, 22 Oct 2007 01:31:05 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
>
> On fast paths we aren't going to add things like get_unaligned()
> calls.
>
> Every architecture should handle unaligned accesses properly, and for
> the fast paths the network driver should provide the packet f
From: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 09:23:50 +0200
> As for other instances of unaligned accesses, is there any active
> work on getting rid of those? And would you accept more patches for
> fixing them? (Code complexity being the downside)
On fast paths we aren't going
On Sun, 21 Oct 2007 22:15:24 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
>
> Sure. But the language defines that the types in question
> must be 64-bit aligned, so it is legal for the compiler to
> emit this code.
>
> It's not a GCC bug.
>
I've confirmed this behaviour on the AVR32 ar
From: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 06:54:43 +0200
> On Sun, 21 Oct 2007 16:02:15 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > You will get a 64-bit load and a 64-bit store emitted by
> > the compiler. Here is what we get on sparc64:
>
> I assume those
On Sun, 21 Oct 2007 16:02:15 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Pierre Ossman <[EMAIL PROTECTED]>
> Date: Sun, 21 Oct 2007 23:21:13 +0200
>
> > Not sure that would be valid. memcpy() is defined as having void*
> > arguments, and the compiler cannot just ignore that if it
From: Pierre Ossman <[EMAIL PROTECTED]>
Date: Sun, 21 Oct 2007 23:21:13 +0200
> Not sure that would be valid. memcpy() is defined as having void*
> arguments, and the compiler cannot just ignore that if it chooses to
> inline it.
Yes it can, there are C language rules about the alignment of types
On Sun, 21 Oct 2007 12:48:14 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
>
> You are missing a crucial point.
>
> The compiler may emit the same exact loads and stores when it inlines
> memcpy() if it "knows" the objects are aligned properly. And it very
> much will do this.
>
Not sur
From: Pierre Ossman <[EMAIL PROTECTED]>
Date: Sun, 21 Oct 2007 11:34:05 +0200
> Inlining isn't the problem, but the defined semantics of assignment
> versus memcpy(). memcpy() must work on any region of memory, whilst
> assignment must only work on a properly aligned object.
You are missing a cru
On Sat, 20 Oct 2007 22:12:57 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Pierre Ossman <[EMAIL PROTECTED]>
> Date: Sat, 20 Oct 2007 23:35:40 +0200
>
> > Structure assignment have to be aligned just like any assignment, and the
> > skb could point to anything. So take the safe rou
From: Pierre Ossman <[EMAIL PROTECTED]>
Date: Sat, 20 Oct 2007 23:35:40 +0200
> Structure assignment have to be aligned just like any assignment, and the skb
> could point to anything. So take the safe route and use a memcpy().
>
> Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Unfortunately
13 matches
Mail list logo
