Re: RFC: IRQ affinity (aka interrupt routing)

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

(2014/08/21 15:30), Martin Husemann wrote:
> On Thu, Aug 21, 2014 at 10:50:53AM +0900, Kengo NAKAHARA wrote:
> > I think it is easy to set affinity by IRQ number with above output.
>
> Yes, and would be even better if the device/interrupt name would be
> allowed as well (intrctl could internally translate it)

I see, it is good. I will support it future. :)

> > > I am not sure we have a globally unique number available on all
> > > architectures
> > > to describe any interrupt.
> >
> > I am not sure too. If the architecture does not have a unique number to
> > describe interrupts, it may be difficult for the architecture to  support
> > thisfeature. I do not think about the architectures other than x86 yet.
>
> I suppose everyone has numbers at some level, but it may be a tree, or at
> least multiple PICs at the root. If we need numbers, we can assign them
> uniquely via a dfs traversal or similar (or by assigning an incremental
> one whenever the relevant *_intr_establish() function is called).
>
> However, I am not sure this is the best aproach. We have made everything
> else properly machine independend, see for example pci_intr_establish, the
> MD definition of pci_intr_handle_t and pci_intr_string. I think we should
> use similar techniques here.

Thank you for information and idea. When it support multi architecture,
it must use abstruct identifiers of interrupt like pci_intr_handle_t.
It may be good to use the device name as the identifier. It it not good
to implement different userland option for each architectures.

At any rate, I need to consider a way to make the interface MD. I cannot
implement IRQ affinity for the architectures other than x86 immediately,
but I try to design the interface to be MD.

Thanks,

--
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>