Re: [PATCH 17/25] x86_64 irq: Remove the msi assumption that irq ==vector

[Dave Olson]

Eric and I had a brief side discussion, which we thought should
be shared with the other folks interested in this issue.

On Thu, 22 Jun 2006, Eric W. Biederman wrote:
| > Will there any (exported) way for a driver to find out the actual vector
| > corresponding
| > to it's irq?
|
| Not in a good way.  The vector changes at runtime, when the irq
| is migrated between cpus.

Since this has to be handled for MSI in general, it should be possible
to handle it for HyperTransport as well.

Our InfiniPath HT chip has an additional constraint that it needs a callback if
the vector changes, because a register past the config space also
has to change.

Or we have to have a way to disable migration from the driver (probably
not a bad idea anyway, for performance sensitive drivers), or both.

| > If not, this will break the infinipath HTX driver, which needs to
| > program the vector into the HT config space of our chip (something the
| > MSI infrastructure does for PCI and PCI-e, but which doesn't exist for
| > HT, so I do it myself).
|
| Right we need a cousin of msi layer to implement generic HT interrupt
| support.  Otherwise whatever we implement will be prone to break.
|
| The good news is this should be much easier to implement now than
| it was earlier.
|
| > Before the MSI support changed what request_irq() returned, I either
| > had to do some heuristics to figure out the vector, or hack a way into
| > the kernel so I could get the vector.
|
| So far I see what your driver is doing as a hack, who's only excuse

Agreed.

| is that there isn't generic code to do better.  However now that
| this code isn't scheduled to go in before 2.6.19 I expect we can
| have a generic HT layer before this code reaches a stable kernel.
|
| Looking at the ipath_ht400.c driver your code appears to have the side
| effect of always binding to cpu 0, and always in fix physical mode.
| Ok on small systems but probably not what you want on systems with
| multiple instances of this chip.

Definitely not what's wanted for multiple instances on large systems in
all cases (from a cache perspective, multiple adapters interrupting on
the same processor isn't necessarily bad, but beyond 2 per cpu is
a real problem with openib, in terms of available cpu cycles).

| I was thinking earlier because of the on the wire similarities I could
| share msi_ops between the implementations.  But the HT code really
| implements this quite differently much more like an io_apic in it's
| register layout so I guess a ht_ops is needed.

Probably.

Dave Olson
olson@xxxxxxxxxxxx
http://www.unixfolk.com/dave

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