[openib-general] ip over ib throughtput

[Grant Grundler]

On Tue, Jan 04, 2005 at 04:38:45PM -0800, Roland Dreier wrote:
> No, mthca is blissfully unaware of the details of assigning MSI
> vectors. 

Ok

> I'm talking about drivers/pci/msi.[ch], which currently have
> a very simple msi_address_init() function that assumes Intel-style
> addresses, and similarly encode Intel-style message contents.

I don't think those are Intel specific:

#define MSI_ADDRESS_HEADER              0xfee
#define MSI_ADDRESS_HEADER_SHIFT        12
#define MSI_ADDRESS_HEADER_MASK         0xfff000
#define MSI_ADDRESS_DEST_ID_MASK        0xfff0000f


PA-RISC platforms since 1999 (about) use the same address range:

| 2.5.1        PCI Interrupt transactions
| When a PCI device does a Memory Write transaction to the 1MB address
| range starting at 0xFEE0_0000. The PSC claims the transaction and puts
| the address and data into the WPF, identifying them as interrupt address
| and interrupt data. The transaction makes its way to the Ibus. The MBIB
| subsequently does an interrupt transaction on the Merced bus with the
| same address and data, but using the Merced bus encoding for an interrupt
| transaction.

(N-class PA-RISC boxes had a Merced Bus)


Page 12 of 57 of the ZX1 Mem/IO Controller Doc has the system
address map and also places the interrupt block at 0xfee00000.

I wondered if the MSI_ADDRESS_HEADER_SHIFT needed to be 20 instead
of 12 (and it doesn't):
static void msi_address_init(struct msg_address *msi_address)
{
...
        dest_id = (MSI_ADDRESS_HEADER << MSI_ADDRESS_HEADER_SHIFT);
...
        msi_address->lo_address.u.dest_id = dest_id;
...
}

but "struct msg_address" uses bit fields to put dest_id in the right
location of the "vector". At least I expect it's the right location
since MSI-X seems to work for other little endian arches.

I'll keep looking.

thanks,
grant