
Hi Scott and Zuki, Thank You for the prompt reply. The sgo problem has been resolved now. But may I know under what circumstances does one use "pcireset" ? This program hangs my machine too. I still could not figure out the problem with ping. 192.168.133.38--->[Port 1]Vera[Port 0]--->192.168.133.147 My routing cache is as follows: /* original */ {"192.168.133.38", "192.168.133.147", "00:E0:29:00:8A:57", "00:E0:29:00:8C:AE", 0x00}, {"192.168.133.147", "192.168.133.38", "00:E0:29:00:8C:AE", "00:E0:29:00:8A:57", 0x01}, /*mirror*/ {"192.168.133.38", "192.168.133.147", "00:E0:29:00:8A:57", "00:E0:29:00:8C:AE", 0x01}, {"192.168.133.147", "192.168.133.38", "00:E0:29:00:8C:AE", "00:E0:29:00:8A:57", 0x00}, Could I confirm that the last parameter ie. "0x00 or 0x01" points to the port that the microengines is supposed to transmit out ? a) The ETHsrc and ETHdst entries in the cache refer to the addresses to be put on the packet. If the ETHdst address does not match the computer to receive the packet the ping might not be recorded. I am still stuck at the point where the microengines can only receive. For each packet received, the SA repeatedly reads and writes as pointed out. None of the packet is transmitted. b) There might not be any microengines servicing the ports. What are the XMT_UE_BASE, XMT_CTX values in Libixprouter/common/src/config.h First, I used the original values: #define RCV_BASE_UE 0 #define RCV_UE_COUNT 2 #define RCV_CTX_COUNT 8 #define XMT_BASE_UE 4 #define XMT_UE_COUNT 2 #define XMT_CTX_COUNT 8 Control_BootUEs gives tid 16, pid 1, ntid 20 tid 20, pid 2, ntid 17 tid 17, pid 3, ntid 21 tid 21, pid 4, ntid 18 tid 18, pid 5, ntid 22 tid 22, pid 6, ntid 19 tid 19, pid 7, ntid 23 tid 23, pid 0, ntid 16 tid 0, pid 1, ntid 4 tid 4, pid 2, ntid 1 tid 1, pid 3, ntid 5 tid 5, pid 4, ntid 2 tid 2, pid 5, ntid 6 tid 6, pid 6, ntid 3 tid 3, pid 7, ntid 7 tid 7, pid 0, ntid 0 Does that mean uengine 0 to 1 are activated for receive and uengine 4 and 5 are activated for transmit ? Now if I change it as such and recompile everything: #define RCV_BASE_UE 0 #define RCV_UE_COUNT 4 #define RCV_CTX_COUNT 16 #define XMT_BASE_UE 4 #define XMT_UE_COUNT 2 #define XMT_CTX_COUNT 8 It means uengine 0 to 3 are utilised for receive and the remaining for transmit ? But the Control_BootUEs remains the same as above. c)I turned on Debugging and recompiled the ue source. But I did not get any new message other than the SA's messages on the minicom console. Am I missing something ? 4)I am interested in the layout of the queue in the memory and how this layout is mapped to the 8 ports. #define QUEUE_NO_BITS 3 #define XMT_Q_COUNT (1 << QUEUE_NO_BITS) This means I have 8 queues per port ? Thank You once again and kind regards, cheewei

On Fri, Feb 01, 2002 at 09:38:39PM +0800, Tan Chee Wei wrote:
The sgo problem has been resolved now. But may I know under what circumstances does one use "pcireset"? This program hangs my machine too.
The pcireset program does the same thing as the '-r' option to sgo. For the IXP1200 evaluation board, it doesn't work reliably. To reset the IXP1200 evaluation board reliably, you need to use the reset pin on the board. The pcireset program works just fine for the RAMiX PMC694 board. Scott

Cheewei,
Hi Scott and Zuki,
Thank You for the prompt reply. The sgo problem has been resolved now. But may I know under what circumstances does one use "pcireset" ? This program hangs my machine too. I still could not figure out the problem with ping. 192.168.133.38--->[Port 1]Vera[Port 0]--->192.168.133.147 My routing cache is as follows: /* original */ {"192.168.133.38", "192.168.133.147", "00:E0:29:00:8A:57", "00:E0:29:00:8C:AE", 0x00}, {"192.168.133.147", "192.168.133.38", "00:E0:29:00:8C:AE", "00:E0:29:00:8A:57", 0x01}, /*mirror*/ {"192.168.133.38", "192.168.133.147", "00:E0:29:00:8A:57", "00:E0:29:00:8C:AE", 0x01}, {"192.168.133.147", "192.168.133.38", "00:E0:29:00:8C:AE", "00:E0:29:00:8A:57", 0x00},
Could I confirm that the last parameter ie. "0x00 or 0x01" points to the port that the microengines is supposed to transmit out ?
a) The ETHsrc and ETHdst entries in the cache refer to the addresses to be put on the packet. If the ETHdst address does not match the computer to receive the packet the ping might not be recorded. I am still stuck at the point where the microengines can only receive. For each packet received, the SA repeatedly reads and writes as pointed out. None of the packet is transmitted.
a) To setup ping between two machines the cache table in ipmm.c should look like this: Ping between 10.0.4.2 (whose MAC address is 00:C0:F0:4D:1C:4F and is connected to port 0) and 10.0.2.2 (whose MAC address is 00:C0:F0:4D:1C:4F and is connected to port 1) use the following lines: ---- BEGIN CODE ---- /* Connect 10.0.4.2 and 10.0.2.2 .*/ /* IP Src IP Dst ETH Src Eth Dst Port */ {"10.0.4.2", "10.0.2.2", "12:34:56:78:9A:BC", "00:C0:F0:4D:1B:E1", 0x01}, {"10.0.2.2", "10.0.4.2", "DE:F0:12:34:56:78", "00:C0:F0:4D:1C:4F", 0x00}, ---- END CODE ---- As you see the Eth Src field refers to the MAC address of the port on the IXP1200. Since there are no numbers assigned, I use the easily identifiable sequence 1,2,3, ..., F, 0, 1, ... The port field corresponds the to desired output port.
b) There might not be any microengines servicing the ports. What are the XMT_UE_BASE, XMT_CTX values in Libixprouter/common/src/config.h First, I used the original values: #define RCV_BASE_UE 0 #define RCV_UE_COUNT 2 #define RCV_CTX_COUNT 8
#define XMT_BASE_UE 4 #define XMT_UE_COUNT 2 #define XMT_CTX_COUNT 8
Control_BootUEs gives tid 16, pid 1, ntid 20 tid 20, pid 2, ntid 17 tid 17, pid 3, ntid 21 tid 21, pid 4, ntid 18 tid 18, pid 5, ntid 22 tid 22, pid 6, ntid 19 tid 19, pid 7, ntid 23 tid 23, pid 0, ntid 16 tid 0, pid 1, ntid 4 tid 4, pid 2, ntid 1 tid 1, pid 3, ntid 5 tid 5, pid 4, ntid 2 tid 2, pid 5, ntid 6 tid 6, pid 6, ntid 3 tid 3, pid 7, ntid 7 tid 7, pid 0, ntid 0
Does that mean uengine 0 to 1 are activated for receive and uengine 4 and 5 are activated for transmit ? Now if I change it as such and recompile everything: #define RCV_BASE_UE 0 #define RCV_UE_COUNT 4 #define RCV_CTX_COUNT 16
#define XMT_BASE_UE 4 #define XMT_UE_COUNT 2 #define XMT_CTX_COUNT 8 It means uengine 0 to 3 are utilised for receive and the remaining for transmit ? But the Control_BootUEs remains the same as above.
b) Changing config.h and recompiling should give a different output. Your interpretation of the parameters is correct. Did you modify commong/src/config.h or common/include/config.h? You should modify src/config.h and then 'make install' in common.
c)I turned on Debugging and recompiled the ue source. But I did not get any new message other than the SA's messages on the minicom console. Am I missing something ?
c) That's odd also. You should be getting a list of numbers formatted like this: [ 4] 00000004 [ 5] 00000005 [ 6] 00000006 [ 7] 00000007 [ 4] 00000000 [ 5] 00000003 Try 'make distclean' and then recompile, it should give you this output.
4)I am interested in the layout of the queue in the memory and how this layout is mapped to the 8 ports. #define QUEUE_NO_BITS 3 #define XMT_Q_COUNT (1 << QUEUE_NO_BITS) This means I have 8 queues per port ?
4) Yes, you are quite right. By default it does seem to be set to 8 queues. The maximum available is 16 since the format of the rcvDecision register in rcv.uc is +---------------------------------------------------------------+ |3|3|3|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|0|0|0|0|0|0|0|0|0|0| |1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0| +---------------------------------------------------------------+ | Queue | Port | Address of the last byte of the packet. | +---------------------------------------------------------------+ If you want to have 16 queues you can use all change QUEUE_NO_BITS to 4. The only thing you have to consider is that on some revisions of the board (e.g. B0) SRAM locking does not work from the StrongARM so the StrongARM can not lock the queue when it's trying to insert packets. You might want to reserve a queue for the StrongARM and not let the microengines use all the queues.
Thank You once again and kind regards,
We're glad to help. Zuki -- Yitzchak Gottlieb zuki@CS.Princeton.EDU
participants (3)
-
Scott C. Karlin
-
Tan Chee Wei
-
Yitzchak M. Gottlieb