Thanks Michael. I looked up the Intel supplied microblocks for SlowIngress and found that before sending out a rcv_request, a macro CONSUME_START_RCV is used. ============================================================================= // This macro will consume a start receive signal, if present. // It is used as a safety net to catch start_receive signals // sent from the IXF440 that we don't expect #macro CONSUME_START_RCV() .local $ignored br_!signal[start_receive, skip#], guess_branch nop csr[read, $ignored, rcv_cntl], ctx_swap skip#: .endlocal #endm ============================================================================= Instead of doing this, I was inserting a delay loop after reading the port status and before sending a rcv_request, since without the delay loop, I get incorrect status in the rcv_cntl register. ============================================================================ get_port_status .if (we_have_a_packet) .local count set [count, 0] .while(count < 0x55) alu [ count, count , + , 1] .endw .endlocal .endif issue_recv_request ============================================================================ This loop is slowing down my input contexts. So maybe instead of this loop, I need to use the CONSUME_START_RCV macro. But when I use the instruction, br_!signal[start_receive, skip#], guess_branch I get the following assembler errors. ERROR: Invalid text follows macro reference ERROR: Wrong number of arguments for macro : 2 shoule be 1. Wierd, because the Programmers Reference Manual specifies exactly the same format that I am using above. Any ideas/pointers? Also, after taking a look at the Intel SlowIngress microblock, I think my critical sections are a little too large. I will try shrinking them too and see what happens. - Abhijeet On Tue, 26 Mar 2002, Michael E. Kounavis wrote:
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