Well, I don't see the point in arguing this further, so that's it.
Let's just hope your patch never gets in (unless somebody can
actually show a path where it will make a difference (without
hacking up kmalloc etc ;) ).
> >(3) it's the IP checksum
>
> The alignment of the skb->data has _nothing_ to do with TCP/IP. If you
> start odd will finish odd and you'll still have a valid IP packet.
you were saying "changing the define of MAX_HEADER for a new protocol
would break the csum"
> But you missed (c):
>
> (c) you do something like what tunnelling does, but you'll store a not
> 32byte aligned information in the hard-header of the skb.
no, i didn't miss it, but ... I don't feel like starting this thread
over again.
> >> >the <686 csum_partial_copy_generic already does align the destination.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> Where?? The only time %edi is changed is after every unrolled loop where
> >> is incremented of 64 bytes.
> >
> >look again
>
> Looked _again_ and I think to have guessed what you was talking about:
>
> #if CPU!=686
> -------^^---
there was no need to guess - in this case "!=686" is the same as "<686".
> (Still running fine with `kmalloc()&1==1' :-).
care to run a few benchmarks? :^)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/