On Mon, 24 Dec 2007 19:45:23 +
Al Viro <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 24, 2007 at 11:36:38AM -0800, Stephen Hemminger wrote:
> > > you will get the same behaviour on big- and little-endian boxen, even
> > > though
> > > the intermediate integer values will be of course different.
>
On Mon, 24 Dec 2007 18:39:50 +
Al Viro <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 24, 2007 at 02:15:40PM +0100, Andi Kleen wrote:
> > Al Viro <[EMAIL PROTECTED]> writes:
> > >
> > > Checksum is fixed-endian and we want it that way; IOW, what we end up
> > > storing in skb->csum should be fixed-e
On Mon, Dec 24, 2007 at 11:36:38AM -0800, Stephen Hemminger wrote:
> > you will get the same behaviour on big- and little-endian boxen, even though
> > the intermediate integer values will be of course different.
> >
> > skb->csum *must* be stored in the same order on l-e and b-e boxen; that
> > w
On Mon, Dec 24, 2007 at 02:15:40PM +0100, Andi Kleen wrote:
> Al Viro <[EMAIL PROTECTED]> writes:
> >
> > Checksum is fixed-endian and we want it that way; IOW, what we end up
> > storing in skb->csum should be fixed-endian as well.
>
> AFAIK skb->csum is always native endian because it normally
>
Al Viro <[EMAIL PROTECTED]> writes:
>
> Checksum is fixed-endian and we want it that way; IOW, what we end up
> storing in skb->csum should be fixed-endian as well.
AFAIK skb->csum is always native endian because it normally
needs to be manipulated further even for RX.
-Andi
--
To unsubscribe fro
Both variants of skge (drivers/net and drivers/net/sk98lin/ resp.)
have the same problem with rx checksums. They pick checksum from rx
descriptor and use it as-is. Normally that would be the right thing to
do. However, skge is told to byteswap descriptors on big-endian boxen.
Checksum i
