[Click] How works Polling?? more details...

[Eddie Kohler]

Hi Giorgio,

> - using short 64 byte packets and increasing the rate, we have "missed
> frames" in the input nic. We suppose this is related to a memory performance
> bottleneck (the input nic cannot transfer anymore packets to memory ->
> it has no more DMA descriptors -> the DMA ring buffer is a memory
> contained structure -> that's why we suppose the limiting factor is memory).

Are you using Tulips or Intel E1000 nics? I don't know much about the
e1000, but in the Tulip, missed frames are actually a signal of CPU
overload. Our ASPLOS paper (Section 8.4) and my thesis (Section 8.3)
contain our best thoughts on Tulip behaviors.

> - now, the "problem": using long frames (1518 byte), we don't have any
> missed frame in the input nic, but... an enourmously varying latency. The
> growing part of the delay is due to the output queue (from 2us to 2 ms).
> So, the only reasonable idea we have is the the "pull process" has some
> problems... but why ? Considering we have a 32bit/33MHz PCI bus (thus 1024

That sounds like PCI overload, possibly caused by the receiving nic
saturating the bus with data. One way to find out is to turn on ToDevice's
accounting mechanisms (I recently sent mail to the list explaining how),
and see whether the ToDevice was ever "idle". If ToDevice was idle this
means that it chose not to pull packets because the transmit DMA ring was
full. This would also tell you that the pull process was not a problem.

> First idea : the pull phase is delayed due to "external bus activities"...
> If delayed too much, can also be its scheduling time cancelled ?
> I mean, if the pull process (for transferring the packet from the queue to
> the output nic) is delayed too much, can the control return to the push
> phase ?

That's not really the way it works. I bet the pull phase is running just as
much as it should, it's just that the transmitting nic is not able to pull
packets off the dma ring.

Good luck!
Eddie