[ixp1200] Reg receive scheduler.

[Jagannathan Iyer Venkatesan]

 Hi Abhijeet,

Thanks for your email. I am aware of the problem you had talked about. In
fact there is a delay that I have introduced in the scheduler whehever the
scheduler reads the rcv-rdy bits.

But again, there is a chance that the data transfer is slower than the
delay I had introduced. I also tried another handshake method between the
scheduler and worker using inter_thread signal. But with that model, my
scheduler hangs for ever to get a signal from the worker. There is a race
condition which I am hypothising on the basis of "missed" signal.

The schduler does something like :
...
write_receive_request()
wait for interthread_signal()
...


The worker does somethingg like :
read_rv_cntl()
signal(scheduler)
read the data from the fifo()

Now, the problem here is, apart from the scheduler and the worker, there
is the hardware which singals the worker of the availability of the
packet. Now, if the signal by the worker was sent before the scheduler can
execute the ctx_arb [inter_thread], then I felt the singal is missed for
good and the scheduler will wait for ever. Can you tell me if the concept
of missed signal is valid ?


Thanks.
Jagan.


 On Thu, 22 May 2003, Abhijeet Joglekar wrote:

> 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.
> >
> >
>
>