lkml.org 
[lkml]   [2006]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] New firewire stack - updated patches
Pieter Palmers wrote:
> Kristian Høgsberg wrote:
>> Hi,
>>
>> Here's a new set of patches for the new firewire stack. The changes
>> since the last set of patches address the issues that were raised on
>> the list and can be reviewed in detail here:
> .. for some reason I didn't get patch 3/4 and 4/4 on the linux1394-devel
> list, so I'll reply to this one.
>
> I would suggest a reordering of the interrupt flag checks. Currently the
> interrupts that are least likely to occur are checked first. I don't see
> why. I would reorder the check such that ISO interrupts are checked
> first, as they have the most stringent timing constraints and are most
> likely to occur (when using ISO traffic).

All the interrupt handler does is schedule tasklets and they are all handled
before returning to userspace. So not matter how you order them it's going to
take the same time. If you want to defer handling of async traffic to after
your userspace handler has run, you need to schedule a work_struct for
handling the async events.

Having said that, I doubt that the latency between iso interrupt and user
space handler imposed by the irq handler and the tasklets will be a problem.
All the async tasklets do is copy the data out of the DMA buffers, possibly
lookup a corresponding request and eventually call complete() on some struct
completion. The worst case is the bus reset tasklet which does the topology
walk, but even that is pretty fast.

> After processing the ISO interrupts (and maybe the Async ones), a bypass
> could be inserted to exit the interrupt handler when there are no other
> interrupts to be handled. All other interrupts are to report relatively
> rare events or errors (error handling still to be added I assume). The
> effective run-length of the interrupt handler would be shorter using
> such a bypass, especially in the case where there is a lot of ISO traffic.
>
> I'm looking forward to your ISO implementation, and I hope to
> incorporate it into FreeBob really fast.

Sounds great, I'll get to the isochronous receive feature as soon as possible.
I'm open to changing the interrupt handling if we can acheive lower latency,
but we need to be able to measure it before we start making changes.

cheers,
Kristian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-12-20 19:47    [W:0.061 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site