[ixp1200] Re:Evaluation of Vera

[Yitzchak M. Gottlieb]

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 at CS.Princeton.EDU