[ixp1200] Reg receive scheduler.

[Abhijeet Joglekar]

Hi Jagan,

Have you handled the case that your scheduler thread (tid = 0 on ME 0)
is not running so fast that it reads stale rcv-rdy bits? This is now
a well documented architecture problem with slow ports on the IXP1200 and
is explained in IXP1200 Programming book. (I wasted a hell lot of time
debugging this one before it was discussed in the book).

If that is the problem, try slowing down your code by adding delay
loops in your scheduler thread.

Your description that things work fine for 64 byte packets, but not
for larger packets seem to indicate that this could be a problem.
Assuming, the bulk of your processing code runs when an EOP mpacket
is handled (once your entire packet is in the SDRAM), it is likely
that things are fine for 64 byte packets, since every mpkt is an EOP,
so you do enough processing before polling the rcv-rdy bits.
However for larger packets, for SOP/MOP mpkts, the turnaround time
could be small, and your sched. thread could be reading stale recv.
ready bits.

-- abhijeet

On Thu, 22 May 2003, Jagannathan Iyer Venkatesan wrote:

>
> Hi,
>
> I am trying to develop write a packet receive code for IXP1200. I am using
> a scheduler-worker paradigm to do the receive. i.e, my scheduler is in
> microengine 0 and one of its thread (thread 0) checks for availability of
> packet in any of the ports. I have 2 microengines doing the packet receive
> and so there are 8 threads for 8 ports, one thread per port. Two other
> microengines do the transmit (and one ue is free)
>
>
> Actually the code works for packets of length = 64 bytes. (i.e length of
> one chunk). But when the size of the packet increases, the data read from
> the FIFO is corrupt. I can give more details on this if anyone is
> interested.
>
> /* some of the details that could be of interest at this time:
> 1) I am not using autopush. My scheduler reads the rcv_rdy_lo register.
> 2) The scheduler constructs the rcv_req with the thread id responsible for
> that port.
> 3) The reading of rcv_cntl is done by the worker after it gets the
> start_receive signal
> 4) The worker read the packet and processes it.
> 5) The packet that gets corrupt is usually the first workd of the IP
> packet (version, etc)
> */
>
> Thanks a lot.
> Jagan.
>
>