March 2002 - ixp1200 - lists.cs.princeton.edu

Re: [ixp1200] Large packets on the IXP
by Michael E. Kounavis 09 Apr '02

09 Apr '02

Abhijeet, The fact that you have buffer overflows at so low incoming bit rates may be an indication that your IP forwarding code does not serve packets "quickly enough" so that each packet is being proceesed during a period of time that is larger than the time it is supposed to spend in a microengine. Could be a problem with your code. Or it could be a by-product of bad thread scheduling. Check when your threads swap context. I suggest to test your code using the Developer Workbench carefully. -- Michael

3 3

RE: [ixp1200] packet to strong arm
by Heaton, Eric D 30 Mar '02

30 Mar '02

Ravi, Just to make clear, the use of "port 18" is only the software design used in our example designs. Basically, it is a software maintained queue that the SA Core is polling for exception packets. As far as the basic methodologies for Core/Microengine communication, you would use shared memory (SRAM/SDRAM) and the use of interrupts/signals. As far as the actual mechanism, like using mailboxes, linked lists or circular queues, it is up to the programmer. Eric Heaton Technical Marketing Engineer Intel Corporation - NPBU -----Original Message----- From: Johnson, Erik J [mailto:erik.j.johnson@intel.com] Sent: Wednesday, March 20, 2002 12:35 PM To: 'ixp1200(a)CS.Princeton.EDU' Subject: RE: [ixp1200] packet to strong arm > My question is... > 1)Is there any major modification to be done in the > code to run a project written for a 64 bit > bidirectional IXbus mode to make it run on 32 bit > unidirectional IXBus mode?? >From a software perspective, no. That is, you don't need to change the receive or transmit microcode. The hardware must agree upon the format (i.e., the MAC and IXP1200 must both be using the same mode) > 2)what exactly is the communicaton mechanism between > the microengines and the core?What I have understood > is that the receive thread creates a descriptor which > contains info about which port to send the packet > to,and then the transmit thread reads this descriptor > and transmits the packet to the specified port.But in > this case the port number is 18,then how does trasmit > thread make use of this port 18.Please correct me if I > am wrong. In the reference designs, port 18 is not handled by the transmit microengines. Rather, when the ingress code enqueues a descriptor on port 18, the PETH driver (or any other software you want) running in the core dequeues the descriptor and hands it (usually) to the IP stack of the OS. When the core needs to transmit a packet, it directly enqueues on the transmit queue for the outgoing port. Note that a similar model is taken by the microblocks/microACE model in IXA SDK 2.0, but the actual implementation is a bit different. In this model there are also queues between the microengines and core, but these queues avoid core/microengine locks and there are APIs for demultiplexing the packets on either side of the queues to the appropriate piece of core or microengine code. > > Thanks and regards > Ravi Modgekar >

2 1

Updated SDK available
by Brandewie, Dirk J 29 Mar '02

29 Mar '02

For those of you that were missed by the update mail there is a updated version of the IXA SDK available v2.01 and an update to the new release v2.01a. You can find ordering information for the SDK at: http://www.intel.com/design/network/products/npfamily/sdk2.htm (bottom of page) and the update for the SDK at: http://www.intel.com/design/network/products/npfamily/sdk2a.htm Enjoy --Dirk

1 0

Having trouble with the IXP1200
by KHACHCHOU Mohammed 29 Mar '02

29 Mar '02

hello everybody, It will be great if someone can help me. I am working on a card delivered by Intel (ENP-2505) wich is based on the network processor IXP1200. As a fisrt step of my project, i wanted to port Linux under IXP1200 using cygmon (as described in the IXP1200 HOWTO) but unfortunately i wasn't able to start the tftp session. I tought that cygmon was corrupted, so i wanted to flash the rom with the "flash.img" delivered by Intel (in IXA SDK, with FUtil Version 2.0.83) and then it was the hecatomb because when i want to boot on cygmon it no longer gives the hand. I think that what i need now is the "flash.img" which contains the available cygmon for the card and some documentation about how to flash the rom (if it is different then the IXP1200 HOWTO). Ofcourse, when Intel sent me the card i had some docs with it but the problem was that these docs wasn't compatible whith the card (and i think that the SDK is not compatible also) PS: Please don't hesitate to send me anything that you find interresting about this subject, as soon as possible because i am in a hurry. Description of the Card: ENP2505 (PCI packet Processing engines) - Intelligent packet processing engines. - Intel 232Mhz IXP1200 network processor based - Flexible I/O configurations - Four 10/100 Mbit Ethernet - Standard PCI form factor - 256 Mbytes SDRAM - 8 Mbytes SRAM - 8 Mbytes Flash Thanks a lot -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- KHACHCHOU Mohammed Ann�e : 2i�me Fili�re : T�l�communiations Ecole : E.N.S.E.I.R.B T�l : +33 (0) 6 51 15 17 Mail : khachcho(a)enseirb.fr -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

1 0

Large packets on the IXP
by Abhijeet Joglekar 26 Mar '02

26 Mar '02

Hi, I am using the Princeton firmware and Vera software as the base, but WITHOUT the Vera model, in which you can plugin forwarders into the input processing loop. I am basically trying to let the input thread just move packets as fast as it can into the DRAM . (something akin to vera with IP-- hardcoded into the input loop) I am having problems with higher packet rates for large packets. So for 1500 byte packets, I can pump in 1250pps (which is 15Mbps approx) across a pair of ports. But if I try to split this load across two sets of ports, i.e send in 625pps, then I start getting port overflows. To avoid these overflows, I have to reduce the rate to almost like 3Mbps with 1500 byte packets. I am currently using only 1 FIFO slot and 64 bytes on the port buffer. Will using more slots from the FIFO (for eg. I can use 4 slots per port if I am only supporting 4 ports) and maybe 128 bytes on the port reduce the overflows significantly or by a appreciable factor? If there are any INTEL folks on this list, can you point out or advise whether the overflows could just be due to the input contexts not been able to get back to the port fast enough? Will draining out the entire packet at one go and then passing control to the other contexts work better than draining out 1 MP at a time and then immediately passing control to the other thread? Maybe draining out the entire packet would result into overflows on the other ports and would be no better? I have the ACE framework from Intel set up too, so maybe I can try out the same experiment on that and see how it behaves for large packets. I am not sure if I am very clear with my questions, but if somebody wants, I can reclarify. Thanks, - Abhijeet

1 0

Vera Software update
by Yitzchak M. Gottlieb 25 Mar '02

25 Mar '02

We are very happy to announce an update of the VERA Runtime libraries and the Vera IXPRouter library. This is mostly a minor update to correct small problems in compiling and using the IXPRouter library. Some relevant changes include: 1) Instructions on using WINE to compile microassembly code. 2) An enhanced user interface for the router 3) Various small bug fixes. The software is available at http://www.cs.princeton.edu/nsg/vera. Please feel free to post any questions. Zuki (for Scott Karlin and Wen Xu) -- Yitzchak Gottlieb zuki(a)CS.Princeton.EDU

2 5

L3Fwd2f project.....
by ravi modgekar 23 Mar '02

23 Mar '02

hi, I was trying to run the L3FWD2F project on the Eval board which has 16 10/100 ports and 2 gig ports.But I couldnt make it work. I have tried using the ixf1002 both in external loopback mode and internal loopback mode.I was using the peth driver compiled for ixf1002 to generate icmp packets. Did I miss something while configuring?? Does the PETH driver set up mac address for ixf1002? If anybody has tried this please help me out. Thanks and Regards Ravi __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/

1 0

RE: [ixp1200] packet to strong arm
by Johnson, Erik J 20 Mar '02

20 Mar '02

> My question is... > 1)Is there any major modification to be done in the > code to run a project written for a 64 bit > bidirectional IXbus mode to make it run on 32 bit > unidirectional IXBus mode?? >From a software perspective, no. That is, you don't need to change the receive or transmit microcode. The hardware must agree upon the format (i.e., the MAC and IXP1200 must both be using the same mode) > 2)what exactly is the communicaton mechanism between > the microengines and the core?What I have understood > is that the receive thread creates a descriptor which > contains info about which port to send the packet > to,and then the transmit thread reads this descriptor > and transmits the packet to the specified port.But in > this case the port number is 18,then how does trasmit > thread make use of this port 18.Please correct me if I > am wrong. In the reference designs, port 18 is not handled by the transmit microengines. Rather, when the ingress code enqueues a descriptor on port 18, the PETH driver (or any other software you want) running in the core dequeues the descriptor and hands it (usually) to the IP stack of the OS. When the core needs to transmit a packet, it directly enqueues on the transmit queue for the outgoing port. Note that a similar model is taken by the microblocks/microACE model in IXA SDK 2.0, but the actual implementation is a bit different. In this model there are also queues between the microengines and core, but these queues avoid core/microengine locks and there are APIs for demultiplexing the packets on either side of the queues to the appropriate piece of core or microengine code. > > Thanks and regards > Ravi Modgekar > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ >

1 0

packet to strong arm
by ravi modgekar 20 Mar '02

20 Mar '02

hi, I am new to ixp1200...I am facing a problem understanding how the microengines transfer packets to the strong arm. I am working on a project using IXP1250 which has an IXF1002 connected .Now I am using L3Fwd2F reference project as my base project to write code for this board. My question is... 1)Is there any major modification to be done in the code to run a project written for a 64 bit bidirectional IXbus mode to make it run on 32 bit unidirectional IXBus mode?? 2)what exactly is the communicaton mechanism between the microengines and the core?What I have understood is that the receive thread creates a descriptor which contains info about which port to send the packet to,and then the transmit thread reads this descriptor and transmits the packet to the specified port.But in this case the port number is 18,then how does trasmit thread make use of this port 18.Please correct me if I am wrong. Thanks and regards Ravi Modgekar __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/

1 0

Shared memory on IXP:
by Ashley Thomas 20 Mar '02

20 Mar '02

hi all, Has anyone used shared memory on IXP ? We tried a simple program which ran fine on ilab m/c but gave this error on ixp (after X-compilation of course with mbig-endian) Failed:: Invalid argument this was the program: #include <stdio.h> #include <sys/shm.h> #include <sys/stat.h> main() { int segment_id; char * shared_memory; int segment_size; const int shared_segment_size = 0x6400; if( (segment_id = shmget(1234,shared_segment_size,IPC_CREAT | IPC_EXCL|S_IRUSR|S_IWUSR) ) < 0) { perror("Failed:"); exit(0); } printf("Id - %d\n",segment_id); shmctl(segment_id,IPC_RMID,0); } -ashley -Ashley Thomas (athomas(a)cc.gatech.edu)

2 1