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! [EMAIL PROTECTED]
----------------------------------------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
