[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