- ixp1200 - lists.cs.princeton.edu

loking for priority scheduling examples
by tomer 17 Sep '02

17 Sep '02

hi , I am running the software release microcode "pfwd16" and I am looking for receive and transmit schedulers microcode examples on priority scheduling. thanks.. rotem.

1 0

Call for Papers: IEEE Network Magazine -- special issue on Networ k Processors: Architectures, Tools and Applications
by Vin, HarrickX 13 Sep '02

13 Sep '02

Our apologies if you receive multiple copies of this announcement. CALL FOR PAPERS IEEE Network Magazine Special Issue on Network Processors: Architectures, Tools, and Applications Guest Editors: Raj Yavatkar Prof. Harrick Vin Intel Corporation Department of Computer Sciences 2111 NE 25th Avenue, JF3-462 University of Texas at Austin Hillsboro, OR, 97124 Austin, TX 78712-1188 raj.yavatkar(a)intel.com vin(a)cs.utexas.edu Tel: (503) 264 9077 Tel: (512) 471-9732 Scope: The rapid and pervasive evolution of the Internet has created an insatiable need for supporting sophisticated services and high bandwidth at both edges of the network and within the network infrastructure. Traditionally, telecom and datacom equipment vendors have used fixed-function ASICs to implement packet-processing functions in hardware. However, such ASICs provide little flexibility when the type or nature of the media interfaces change or new protocol standards require changes to lookup operations or header processing. To meet the demand for higher performance, flexibility, and economy, an alternative to ASICs, called network processors (NPs), has emerged. These processors are programmable and their designs are optimized for processing packets; they can be used to implement efficiently a wide range of network services such as IP datagram forwarding, label switching, content-based routing, voice-over-packet, VPNs, and Quality of Service (QoS). We use the term network processor here in a generic sense to represent devices ranging from task-specific processors, such as classification and encryption engines, to more general-purpose, programmable packet or communications processors. Because many of these NPs are programmable, they offer a significant advantage over ASICs as new features or functions can be introduced or modified easily without having to re-design a network component. Design and development of networking systems using network processors is an emerging field that offers numerous challenges and opportunities. The goal of this special issue is to publish contributions from both industry and academia that describe the state-of-the-art in the architecture, design, programming, software tools, and use of network processors. Papers with tutorial/survey content are also welcome. Topics of particular interest include (but are not limited to): * Architectures for network processors * Novel product designs based on NPs * Co-processors for search/lookup, packet classification, compression, encryption and security, etc. * Design and implementation of new techniques/algorithms for QoS, voice-over-packet, wireless communication, etc * Programming languages, tools, and development environments for software development on NPs * Benchmarking and performance analysis * Interfaces to high-speed packet buses and switch fabrics * Techniques for accelerating network services * Performance measurement and analysis * Novel applications made possible by NPs Submission Guidelines: Interested authors should submit an electronic version of the manuscript either in Postscript or PDF format as an email attachment to one of the guest editors. Additional information including "Guidelines for authors" is available at the IEEE Network Website: http://www.comsoc.org/pubs/net/ntwrk/authors.html Important Dates: Paper Submission Deadline: October 30, 2002 Feedback to Authors: February 1, 2003 Final Manuscripts to Publisher: April 1, 2003 Publication of Special Issue: July 2003

1 0

reading statistics registers from the ixf440 ( ixp12eb)
by tomer 12 Sep '02

12 Sep '02

Hi I am working on the ixp12eb supported by the vxworks os. I am trying to read the statistic registers from the ixf440, so far no success. I went through your example codes. In the control.c file ( libixprouter.tar ) i saw that you use the scratchRead32( ) function to do the job. I could not find this function. Can you advise me on this matter? You my find this Q too obvious, but i am a beginner on the system, anything is helpful to me. thanks Tomer.

3 4

help, ACE Framework.
by Timen 11 Sep '02

11 Sep '02

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: 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! 　　　　　　　　Timen 　　　　　　　　hhf(a)sunyard.com 　　　　　　　　　　2002-09-12

1 0

SDK 2.01a : Problems in reserving memory for variables
by Yannis Haritakis 09 Sep '02

09 Sep '02

Hi all, Under SDK 2.01a the following problem occured: Eventhough the linker is instructed to use addresses above 0x200 for variables (residing in scratch pad), it falsely allocates space that starts from address 0x0. That means address 0x0 is handled both for a variable declared in scratch pad, and by code that explicitly operates on that address. I have attached the files of a project that demostrate the problem. It can easily be demostrated if you run the simulation for 100cycles. Check the references of thread 0. Below is the code : Note that : 1) The linker is instructed of which address space to use for variables via the menu Build->Settings->Linker->Reserved Space for variables 2) The false assigment occurs only in optimize for speed, and optimize for size cases. 3) It only allocates falsely the buf array of thread 0 #include "ixp.h" void main(void) { __declspec(scratch) unsigned int buf[20]; unsigned int i; while (1) { for (i=0; i<20; i=i+1) buf[i] = 1; ctx_swap(); for (i=0; i<20; i=i+1) if (buf[i] == 1) buf[i] = 2; } } If anyone is interested on reproducing the problem i can send the whole project files. (I said If! :-) ) Thanks Yannis Charitakis haritak(a)ics.forth.gr

1 0

Generating packets in the SDK
by Shruti Gorappa 09 Sep '02

09 Sep '02

Hi I have just begun learning about the IXA. I want to try to send some kind of control information to and from my machine (That is running the reference design). I want to know if I can build and transmit control packets using the SDK. Also, is there some way that I can connect the machine that I am using to another machine and bounce control information between them. Thanks! SG

1 0

Multiple newbie questions
by Magesh Kannan 06 Sep '02

06 Sep '02

Hi All, I am trying to get started on learning to program the IXP1200 and have some questions. I have access to the IXP1200 evaluation board and IXA SDK 2.0 1. IXA SDK 2.0 comes with a 60-day free trial of the Microengine C compiler. However, there seems to be a bug in the installation program that prevents me from installing the trial version. If I choose not to enter a license key, the setup aborts without installing anything. Has anyone faced this problem? 2. I am planning to get the Intel book "IXP1200 Programming". The examples in the book are in Microengine C. Given the above problem with SDK 2.0, I may not be able to install even a trial version of the Microengine C compiler. What's the difference between Microengine C and the C used in Vera? Will the book be useful in understanding (say) LibIXPRouter? 3. If I can get hold of the Microengine C compiler, will I be able to use the IXP1200 evaluation board to run the examples in the Intel book? Excuse me if some of these questions are a little off-topic. Thanks for your help, Magesh Graduate Research Assistant Information and Telecommunication Technology Center The University of Kansas Lawrence, KS

1 0

RE: [ixp1200] Fast Ports - sop_seq roll over
by Johnson, Erik J 06 Sep '02

06 Sep '02

I will agree with you, that the most probable is this: the RSM updates SOP_SEQ and pushes the rcv_cntl info into the 4-entry FIFO. That is, changing SOP_SEQ register before the thread reads the corresponding rcv_cntl register. This means that if 4 SOP-MPKTs arrive back to back (that is 4 PACKETS of length 64Bytes arrive back to back), then when a thread reads the rcv_cntl register from the top of the FIFO queue, the SOP_SEQ register will already have changed three more times. Moreover, assuming that a thread executes the above two commands (repeated bellow): > csr_read(sop_seq, sync_none); > csr_read(rcv_cntl, ctx_wait); Both commands will be queued in the same fbi-fifo (in the pull engine). But before that the two commands will have to be queued in the local (to the uengine fifo), and then the Bus Arbiter will decide if both commands will go back to back on the shared bus to the pull engine or if they will be split in order for another microengine to be serviced. If the Bus Arbiter is servicing a microengine until no more requests exist, then we are ok. If not then we have no guarantee. Am I right??? Does anyone have more information?? [Erik J. Johnson] My experiments agree with the above conclusions/assumptions. Namely, the two values do differ. However, I don't think that this is a consequence of the two commands not being serviced "atomically", I think this is entirely due to the fact that the SOP_SEQ is updated immediately by the RSM. erik ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erik J. Johnson Intel Research & Development erik.j.johnson(a)intel.com NOT SPEAKING FOR INTEL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yannis Charitakis haritak(a)ics.forth.gr

1 0

hash unit
by Damien 05 Sep '02

05 Sep '02

Does anyone know exactly what function the hash unit implements? I'm getting weird results for my test hashes and I want to double check it against what I'm supposed to get. --Damien

2 1

RE: [ixp1200] microC development
by Kunze, Aaron 05 Sep '02

05 Sep '02

Najati, If you are using the workbench, the process for loading microC is the same as the process for loading microengine assembly. It's been a long time since I've loaded any code without the microACE framework, so my memory is rusty. :) If your board is running Linux, you have to make sure that the ue.o driver is loaded and that the rs_udebug process is running in the background. Both of these ship with the SDK and can be found in ixasdk/bin/arm-be. Then, in the workbench hardware settings on your development system, say "Connect via Ethernet" and give it the IP address of the debug port of the board. If you are using VxWorks, the development system side is the same, but on the board you need to run VxWorksNetApp.o. There is a readme file with the workbench that can walk you through this process. It is called VxWorksBuild_ReadMe.txt. Hope this helps! Aaron ------------------------ Aaron Kunze Intel Labs aaron.kunze(a)intel.com -PGP Key ID: 0x81124B7C- -NOT SPEAKING FOR INTEL- ------GO BOILERS!!------ > -----Original Message----- > From: Najati Imam [mailto:nrimam0@uky.edu] > Sent: Wednesday, September 04, 2002 1:47 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: Re: [ixp1200] microC development > > > > > Let me clarify this a bit. Development of microC > *microACEs* is not > > supported by Intel in IXA SDK 2.x. Use of microC outside of the > > microACE framework is supported and microC code will run on the > > IXP1200 hardware. > > Oh? thats cool. What does one need as far as run time > environment to do > so? Namely, can one take a uof compiled from the workbench > and start it > on a microengine(s) and if so how? > > guilt >

2 1