[ixp1200] help, ACE Framework.
Timen
hhf at sunyard.com
Wed Sep 11 21:15:08 EDT 2002
hi,
Some problems about IXP1200 troubles me now. I'm running=
2.01 software release.
When I test the Microcode "L3fwd16" with "PETH", I found, if=
I ftp packets (more than 100Mbytes) from a computer to another=
one, the packets transmitting always stop occasionally. And I=
found the reason is that three transmit threads of MicroEngine=
4/5 stop forever. Everytime, always one transmit thread stops at=
the Macro: tx_packetlinklist_read[]. It made me puzzle.
Finally, it seems that I got the answer from the two=
articles: "pethTestplan.doc" and "pethDriverNotes.doc". The=
articles let me know there is a bug in the hardware that=
occasionally causes "sram_read_lock()" fails. And in the Macro:=
tx_packetlinklist_read[], there is exactly an instruction as=
followed:
=09 sram[read_lock, out_xfr_queue_descriptor0,=
in_queue_descriptor_base, in_queue_offset, 2], priority,=
ctx_swap
"The best solution is to eliminate the need to use SRAM CAM=
locks from the core. This can be accomplished with a ring data=
structure that decouples the "producer" and "consumer"=
information. "
Then, I tested the "L3_8_1Gig" microcode project. It=
exactly has this idea. And, finally, I found, when I transmit=
packet again, it runs very well. Never stop.
But, the speed of transmitting packets is just about=
7.6e+02 Kbytes/sec , much lower than "peth"(about 5Mbytes/sec).=
Could you tell me why? Is it caused by ACE Framwork? How can I=
deal with it?
Best regards!
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Timen
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1hhf at sunyard.com
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12002-09-12
More information about the ixp1200
mailing list