Hi.
On Fri, May 30, 2008 at 05:19:30PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
> ok, I see what you are saying now; if a channel gets done during
> talitos_done processing, it'll trigger an interrupt and reset
> priv->status, leaving the tasklet in the dark as to which channel has
> done status, depending on how many channel dones it has already
> processed. I think the only solution here is to call flush_channel on
> each channel, regardless of the bits in the interrupt status - I'll
> send out a patch shortly.
Out of curiosity, what is number of channels? I had simialar issue with
HIFN crypto driver and limited number of descriptor to 80 iirc, since
with that number HIFN traversal did not show perfromance degradataion on
Ghz x86.
> > callback, during that time cached status and priv itself (and tail like
> > in two simultaneous flushes) could change (or not?)
>
> I think you're talking about a different 'status' here; flush_channel's
> local 'status' doesn't resemble priv->status bits in any way, it looks
> at the descriptor header writeback bits for done status, on a per
> descriptor basis. It forwards this descriptor done vs. error status to
> the callback.
>
> priv itself won't change; it's uniquely associated to the device.
I meant descriptor hdr value accessed via it - can it be checked in
tasklet under the lock and in submit path without? Can they correlate
somehow?
--
Evgeniy Polyakov
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
