[ixp1200] Large packets on the IXP

[Abhijeet Joglekar]

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
>