Re: [ECOS] Enabling -O2 option of GCC]

[Andrew Lunn <andrew dot lunn at ascom dot ch>]

Good work.

Let me rise a few issues though.  

1) You need to keep the old scheme as well. The EBSA platform the
ethernet can only DMA to/from the top 1Mbyte, the PCI window. This has
been marked as unbufferable, uncachable. On the ARM its not cheap to
flush the cache. I have to copy the contents of the mbuf into the PCI
window or nothing works.

2) Same problem with receive. I have to copy.


> 	There is one FUNDAMENTAL issue with this and I'm not sure of the
> implications within the network stack. With lots of processor (PowerPc,
> 68K derivaties etc) the data buffer used by the buffer descriptor must
> be 4 byte or 16 byte aligned. This means that the start of the IP header
> (14 bytes from the start of the Ethernet frame) will not be on a
> longword (32 bit) boundary. Everyting I have read/seen seems to indicate
> that the network stack expects the IP header to be 32 bit aligned - I'm
> not sure of the reasons for this?

You are correct. It improves performance when processing the
headers. I guess when Ethernet was designed, 16bit processors were the
norm, so a 14 bytes ethernet header was not considered a problem. Now
a days a 16 byte ethernet header would make life a lot easer at
times. 

> 	I'm not sure if the network stack itself will decide the IP
> header is not aligned and complain - or even worse allocate a new mbuf
> and align it - performing a memcpy!

Nope, it even worse. On the ARM is throws an exception and dies
horribly. ARM cannot do word access to unaligned memory. It has to do
byte or half word accesses which are different assembly instructions.

What you could do it DMA the ethernet header into one mbuf, and DMA
the rest into a second MBUF or cluster. DMAs may not be able to starts on
unaligned boundaries, but they nornally can do any length. So DMAing
the 14 bytes ethernet header should be possible.

Something im working on at the moment is an optimised memcpy. The
i82559 driver is doing lots of memcpy's with either the src or dst
2bytes out of alignment. memcpy handles this badly and does byte by
byte copy. The PCI windows access is slow, but making 4 byte access
rather than 1 word access is horribly slow. So i've written some
routines which do word access to PCI and then half word access to
normal memory. Im getting 3 to 4 times speedup, depending on the size
of data to be copied. I'll be sending the code to Redhat sometime this
week. At the moment its not a general purpose solution. I will only be
putting it into the i82559 drivers. Its also little endian only. I
need time to discuss with RedHat how to generalise the code and maybe
make it part of the pci library and do a big endian implementation
etc.

        Andrew