Re: [microblaze-uclinux] Transmission speed of the Ethernet

[John Williams <jwilliams@itee.uq.edu.au>]

Hi Rahul,

Rahul Sarvadevabhatla wrote:
> Could you tell me what kind of transmission speeds were you getting when 
> you ran the udp protocol? We are getting less than 1mbps and were 
> wondering if it had something to do with how our options are set here.

I did a bit of tweaking but never got it any higher than around 1mpbs. 
If you want to go digging, the candidate is the driver 
(drivers/net/xilinx_emac/), and the IPIF packet FIFO interface, which is 
in arch/microblaze/xilinx_ocp/

Basically, the packet FIFO interface is used to copy data (packets) out 
of the MAC core FIFO and into memory - it currently insists that the 
memory buffer to which the data is copied, must be word aligned.  THat's 
reasonable enough.  However, the problem is that in an ethernet/ip 
packet, the ethernet header is 22bytes long.  This means that after the 
driver strips the ethernet header off the packet, the start of the 
payload (the actual IP packet) is non-word aligned, and that's not 
allowed.

You can see in the driver (xilinx_emac/adapter.c) where I've done an 
ugly memcpy, to copy the main payload of the packet to a word aligned 
address.

The solution as I see it is to optimise the packet fifo routines, to 
allow copy to a non word aligned address, but done in such a way that 
it's still reasonably streamlined.

To be honest, real performance improvements will probably only come from 
abandoning the driver entirely (written by montavista for the v2pro PPC 
linux), and writing a decent streamlined driver from scratch, based 
probably on some existing one (pick one that SnapGear use - they write 
good code! :-)

When montavista did the drivers, they did so in such a way as to make 
use of Xilinx's EDK driver structure - level 0, level 1, and so on. I 
think this was at Xilinx' request.

This is all fine and dandy, except that it is terribly inefficient. 
There are function calls nested 3 deep *inside the interrupt handler* in 
that driver.  They haven't even declared the functions inline to let the 
compiler do some decent optimisations.  This might not matter so much on 
a PPC, but the microblaze wastes a lot of cycles that could be better 
used elsewhere.

I did as much as it took to get it working, and never spent any time on 
optimising the performance.

You can do the quick fix or the real fix, or maybe a combination of the 
two.  It should be trivial to refactor the driver code to make it more 
streamlined, I'd expect at least another 25-50% performance right there. 
   Then, for the big gains, I'd be looking at a complete re-write.  This 
is not as hard as it sounds, if you've got one (or more) existing 
drivers to work from.

Regards,

John

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/