Speed of plb_temac 3.00 on ML403

[jozsef imrek]

On Mon, 12 Feb 2007, Ming Liu wrote:

> You said in your application the data path can bypass the IP stack, the CPU, 
> and with some work even the main memory. How can you achieve that? Then who 
> will process the UDP packets? If you add the work of processing packets in,

a precondition for this to work is to have all your data processing
implemented in hardware, since the CPU will not see the payload of
the udp packets, so it will have no chance to modify it.

the trick is (as i mentioned in my first reply) is to use an IPIF with
address range support (so it looks like a memory), and have the s/g dma
engine of the plb_temac read the udp payload from this "memory" instead
of your system ram.

the packet header (ethernet + ip + udp) in our application is assembled
by a code based on pktgen. you could implement it in hw as well, but there
is no need for that since you can utilize the full gigabit bandwith (this
you have seen.. :), and it is more convinient to have that functionality
in sw.


a quick hack to see this theory working:

1, create a new peripherial with address range support.
 	(start xps -> hardware -> create or import new peripherial,
 	plb bus, no sw reset/mir, no interrupt, no user regs, with
 	burst support, no fifo, with user address range, no dma,
 	no master iface)

 	you might want to replace the bram in the sample code
 	(pcores/*/hdl/vhdl/user_logic.vhd) with a fixed value
 	or a counter.

2, add this core to your design, create and download your new bitfile.

3, modify the source of the plb_temac linux driver. when a packet
 	is sent with fragments a buffer descriptor (bd) will be set
 	up for each fragment. the first bd will be used for the
 	packet header, and the rest of the bd's will point to the
 	the udp payload. so you want to make sure, that the physical
  	address of all but the first bd's is pointing to the physical
  	address of your IPIF's address range (you can find it in your
 	mhs file, search for C_AR_BASEADDR).

 	in adapter.c in xenet_SgSend_internal() search for the loop
 	where a bd is set up for each payload fragment (something like
 	for (i = 1; i < total_frags; i++, frag++)..), and set the
 	phy_addr to the address of your core (ie. phy_addr = 0x70090000;).

 	compile your new kernel, download it.

4, start pktgen with frags = 1 (use pgset "frags 1"). check the
 	payload of the packets sent on the wire (ie. with tcpdump).

 	if you have replaced the bram in step 1 with a fixed value
 	you should see that value. if you have replaced it with a
 	counter you should see the values rolling. if you did not
 	replace the bram, you should see the contents of the bram - it
 	is filled with all zeroes on reset, but you can fill it with
 	any test pattern.



good luck, and let me know how it works!


-- 
mazsi

----------------------------------------------------------------
strawberry fields forever!                       imrek at atomki.hu
----------------------------------------------------------------