Re: [linux-tr] Re: [parisc-linux] IBM TR patch

Re: [linux-tr] Re: [parisc-linux] IBM TR patch

[mike_phillips]

>> it's not broken, the assumptions in ibmtr are.  after you've ioremapped
>> a region, you can call readb/writeb on it.  ibmtr assumes you can just
>> do direct memory accesses.  now, this is something we want to fix,
>> but it's not a bug in the PA code.

Its in ibmtr purely for historical reasons, the driver is quite old and 
was around before the other architectures really came on stream, so we 
never had to worry about issues like this. 

>Then maybe it's best to define the TR_CHECKSUM macro to 0 as default with 

>an exception of architectures where the above assumption in true (i.e. 
>alpha, i386 and maybe ppc, as well) to gain the extra performance boost 
of 
>the IPv4 pre summarisation.

Possibly better to define it based upon the architecture in the code 
itself, either that or remove it altogether. Again because of the age of 
the driver this may be in there for a reason that is not valid anymore.

What I have to ensure is that we don't lose any functionality that we 
already have, i.e. a change for parisc stops i386/alpha/etc from working. 
Also, the pcmcia driver ibmtr_cs relies on ibmtr and, being pcmcia, can be 
used on more architectures and all changes to ibmtr have to be double 
checked against ibmtr_cs. 

Just out of interest, which t/r chipset does the token ring adapter for 
the old 712's use ? If its the tropic chipset I can test on my 712/80. 

Mike Phillips
Linux Token Ring Project
http://www.linuxtr.net

Re: [linux-tr] Re: [parisc-linux] IBM TR patch

[mike_phillips]

> Nope, it's ISA and PCMCIA only.

And MCA.....

Mike

Re: [linux-tr] Re: [parisc-linux] IBM TR patch

[Jochen Friedrich]

Hi Mike,

> What I have to ensure is that we don't lose any functionality that we 
> already have, i.e. a change for parisc stops i386/alpha/etc from working. 
> Also, the pcmcia driver ibmtr_cs relies on ibmtr and, being pcmcia, can be 
> used on more architectures and all changes to ibmtr have to be double 
> checked against ibmtr_cs. 

That's what i did for the changes. I tested them on an Auto 16/4 ISA card 
in a HP 9000/720 and on an Auto 16/4 PCMCIA card in an i586 Laptop. 

I guess the pre-summarisation is there for performance reasons. In 
particular on older architectures, it's probably faster to copy and 
calculate the IPv4 checksum in the same step than to copy and checksum in 
two seperate steps. I'm not sure, if this is still true and if someone 
benchmarked the difference.

> Just out of interest, which t/r chipset does the token ring adapter for 
> the old 712's use ? If its the tropic chipset I can test on my 712/80. 

No clue. I'm just using a spare ISA card in the EISA slot...

--jochen

Re: [linux-tr] Re: [parisc-linux] IBM TR patch

[Jochen Friedrich]

Hi Mike,

> And MCA.....

I doubt that this might be an issue for big endian, unless someone 
*really* starts a Linux port for POWER2 or ports MCA to PPC for the 
early RS/6000 (model 250?) machines.

--jochen

Re: [linux-tr] Re: [parisc-linux] IBM TR patch

[Alan Cox]

> > And MCA.....
> 
> I doubt that this might be an issue for big endian, unless someone 
> *really* starts a Linux port for POWER2 or ports MCA to PPC for the 
> early RS/6000 (model 250?) machines.

That may happen. If the code is endian clean they can fix up the remnants

Re: [linux-tr] Re: [parisc-linux] IBM TR patch

[Grant Grundler]

Jochen Friedrich wrote:
> Hi Mike,
> I guess the pre-summarisation is there for performance reasons. In 
> particular on older architectures, it's probably faster to copy and 
> calculate the IPv4 checksum in the same step than to copy and checksum in 
> two seperate steps.

I believe it's faster on all archs to do this in one loop.
Assuming one has enough registers to do both operations at the same time.
My assumption is anything that can run linux has enough registers.
(ie ld/st does not collide with xor).

grant

RE: [linux-tr] Re: [parisc-linux] IBM TR patch

[drequena]

unsubscribe linux-tr
end

Saludos cordiales,
   David Requena
   Computer Sciences Corporation
   http://www.csc.com
   drequena@csc.com

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender at drequena@csc.com
**********************************************************************

Mensaje original:  owner-linux-tr, 16/01/2002 09:20:12 p.m.

> Hi Daniel,
>
> > I think the driver was correct. The i/o layer should not try to
byteswap
> > the io requests, because it can not second-guess what the driver is
doing.
>
> I guess the 68000 code is the reference here as it was the first BE port,
> and they do the byteswap, as well.
>
> --jochen
>