RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
> Ok. Thanks for clearing it up. So the idea would be that if > pci_enable_msix() for "n" number of messages failed, then > settle down for 1 message, which is equivalent to MSI mode And if that fails to acquire the one vector for whatever reason (MSI isn't enabled, or something is buggy in your chipset), fail back to legacy interrupts. Cheers, -PJ Waskiewicz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Manu Abraham [mailto:[EMAIL PROTECTED] > >Ok. Thanks for clearing it up. So the idea would be that if >pci_enable_msix() for "n" number of messages failed, then settle down >for 1 message, which is equivalent to MSI mode > yep - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
On 7/21/07, Nelson, Shannon <[EMAIL PROTECTED]> wrote: Manu Abraham [mailto:[EMAIL PROTECTED] >Sorry for being not clear. What i was asking is thus: > >A device that has legacy interrupts and MSI-X. I was thinking that if >MSI-X failed one should fall back to MSI mode (single message), that's >what i was assuming. > >In such a case, i do enable MSI-X mode on the device, when the request >for 2 ^ n number of messages (where messages can be a max of 32), If >the request fails one falls into a single message mode, ie MSI ? > > >> What device do you have in mind? > > >The device that i have in mind is a SAA7160. Notice our code looks at the return from pci_enable_msix() - it will give you a hint whether MSI-X is not supported (returns < 0) or you simply asked for too many (returns > 0). If the former, then fallback to legacy; if the latter, try MSI-X with only one interrupt, which essentially emulates MSI mode. Ok. Thanks for clearing it up. So the idea would be that if pci_enable_msix() for "n" number of messages failed, then settle down for 1 message, which is equivalent to MSI mode - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Manu Abraham [mailto:[EMAIL PROTECTED] >Sorry for being not clear. What i was asking is thus: > >A device that has legacy interrupts and MSI-X. I was thinking that if >MSI-X failed one should fall back to MSI mode (single message), that's >what i was assuming. > >In such a case, i do enable MSI-X mode on the device, when the request >for 2 ^ n number of messages (where messages can be a max of 32), If >the request fails one falls into a single message mode, ie MSI ? > > >> What device do you have in mind? > > >The device that i have in mind is a SAA7160. Notice our code looks at the return from pci_enable_msix() - it will give you a hint whether MSI-X is not supported (returns < 0) or you simply asked for too many (returns > 0). If the former, then fallback to legacy; if the latter, try MSI-X with only one interrupt, which essentially emulates MSI mode. sln -- == Mr. Shannon Nelson LAN Access Division, Intel Corp. [EMAIL PROTECTED]I don't speak for Intel (503) 712-7659Parents can't afford to be squeamish. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
On 7/21/07, Roland Dreier <[EMAIL PROTECTED]> wrote: > In a case where you have a device that which supports MSI-X (multiple > interrupts) but the device in default is in MSI mode, ie some > configuration change is needed on the device. In such a case, how > would one handle between MSI-X and MSI ? > > ie the device initially doesn't support MSI-X I don't understand the question really. Does the PCI spec even allow a device to be in MSI mode by default? Surely the OS must initialize the address/message before the device can generate an MSI? Sorry for being not clear. What i was asking is thus: A device that has legacy interrupts and MSI-X. I was thinking that if MSI-X failed one should fall back to MSI mode (single message), that's what i was assuming. In such a case, i do enable MSI-X mode on the device, when the request for 2 ^ n number of messages (where messages can be a max of 32), If the request fails one falls into a single message mode, ie MSI ? What device do you have in mind? The device that i have in mind is a SAA7160. I guess the interesting case is a PCIe device that supports MSI and MSI-X but not legacy interrupts. However I would assume such a device would come up with both MSI and MSI-X disabled. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
> In a case where you have a device that which supports MSI-X (multiple > interrupts) but the device in default is in MSI mode, ie some > configuration change is needed on the device. In such a case, how > would one handle between MSI-X and MSI ? > > ie the device initially doesn't support MSI-X I don't understand the question really. Does the PCI spec even allow a device to be in MSI mode by default? Surely the OS must initialize the address/message before the device can generate an MSI? What device do you have in mind? I guess the interesting case is a PCIe device that supports MSI and MSI-X but not legacy interrupts. However I would assume such a device would come up with both MSI and MSI-X disabled. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
On 7/21/07, Roland Dreier <[EMAIL PROTECTED]> wrote: > This driver supports some chipsets that do MSI, and some that do MSI-X, > but none that can do both. Thanks, that's the simple answer I was hoping for. Obviously if some chipsets only do MSI then you need the MSI code in addition to the MSI-X code. In a case where you have a device that which supports MSI-X (multiple interrupts) but the device in default is in MSI mode, ie some configuration change is needed on the device. In such a case, how would one handle between MSI-X and MSI ? ie the device initially doesn't support MSI-X - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
> This driver supports some chipsets that do MSI, and some that do MSI-X, > but none that can do both. Thanks, that's the simple answer I was hoping for. Obviously if some chipsets only do MSI then you need the MSI code in addition to the MSI-X code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Roland Dreier [mailto:[EMAIL PROTECTED] > >OK, let's try to avoid going off into the weeds here. In the context >of the specific patch that this thread started with, is there any >point in having both "msix-single-vector" and "msi" interrupt support? Some versions of this hardware support MSI-X and not MSI. If it can't get all the MSI-X interrupts, it will try a single interrupt before fallign all the way down to Legacy interrupts. Basically, if we can only get one interrupt, we'd still like to use the MSI-X mechanics if possible. If totally out of the question, then we'll use legacy. sln -- == Mr. Shannon Nelson LAN Access Division, Intel Corp. [EMAIL PROTECTED]I don't speak for Intel (503) 712-7659Parents can't afford to be squeamish. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Roland Dreier wrote: > OK, let's try to avoid going off into the weeds here. In the context > of the specific patch that this thread started with, is there any > point in having both "msix-single-vector" and "msi" interrupt support? This driver supports some chipsets that do MSI, and some that do MSI-X, but none that can do both. - Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
> > Hmm, I see I don't understand what this driver is doing. > > What is a "struct ioatdma_device"? Is this driver requesting > > interrupts that come from the NIC or the IOAT DMA engine? > > I might have caused some confusion. You had asked if any drivers > support MSI but not MSI-X, so I threw 2 drivers out there that currently > support both, and why we support MSI for compatibility. > > > Anyway, if the NICs support MSI-X, is there any chance of > > failing to get one MSI-X vectors but then succeeding in > > getting MSI enabled? > > How could that happen? I don't see what falling back to MSI > > buys you beyond more code. > > MSI-X doesn't make much sense if you have 1 Rx queue on your NIC, since > 1 vector essentially acts like MSI. In the case of why MSI-X could > fail, I have had it fail when I misconfigured my driver and didn't ask > for enough vectors for what I was assigning, so the driver disabled the > multiple Rx queues, and fell back to MSI. OK, let's try to avoid going off into the weeds here. In the context of the specific patch that this thread started with, is there any point in having both "msix-single-vector" and "msi" interrupt support? - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
> Hmm, I see I don't understand what this driver is doing. > What is a "struct ioatdma_device"? Is this driver requesting > interrupts that come from the NIC or the IOAT DMA engine? I might have caused some confusion. You had asked if any drivers support MSI but not MSI-X, so I threw 2 drivers out there that currently support both, and why we support MSI for compatibility. > Anyway, if the NICs support MSI-X, is there any chance of > failing to get one MSI-X vectors but then succeeding in > getting MSI enabled? > How could that happen? I don't see what falling back to MSI > buys you beyond more code. MSI-X doesn't make much sense if you have 1 Rx queue on your NIC, since 1 vector essentially acts like MSI. In the case of why MSI-X could fail, I have had it fail when I misconfigured my driver and didn't ask for enough vectors for what I was assigning, so the driver disabled the multiple Rx queues, and fell back to MSI. I hope this helps. -PJ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
> Both igb (recently posted) and ixgbe (also recently posted) support both > MSI and MSI-X. Right now when we try to request MSI-X vectors, if we > fail to acquire what we've asked for, we fall back to MSI support. If > MSI fails to initialize, we fall back to legacy interrupts. So it needs > to be there in case MSI-X allocation fails for the NIC driver. Hmm, I see I don't understand what this driver is doing. What is a "struct ioatdma_device"? Is this driver requesting interrupts that come from the NIC or the IOAT DMA engine? Anyway, if the NICs support MSI-X, is there any chance of failing to get one MSI-X vectors but then succeeding in getting MSI enabled? How could that happen? I don't see what falling back to MSI buys you beyond more code. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
> -Original Message- > From: Roland Dreier [mailto:[EMAIL PROTECTED] > Sent: Friday, July 20, 2007 10:43 AM > To: Nelson, Shannon > Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Williams, Dan J; Leech, > Christopher; Waskiewicz Jr, Peter P > Subject: Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X > > are there any devices that support MSI but not MSI-X? If > not, is there any point in having code to support both? > > - R. > Both igb (recently posted) and ixgbe (also recently posted) support both MSI and MSI-X. Right now when we try to request MSI-X vectors, if we fail to acquire what we've asked for, we fall back to MSI support. If MSI fails to initialize, we fall back to legacy interrupts. So it needs to be there in case MSI-X allocation fails for the NIC driver. Thanks, -PJ Waskiewicz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
are there any devices that support MSI but not MSI-X? If not, is there any point in having code to support both? - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
are there any devices that support MSI but not MSI-X? If not, is there any point in having code to support both? - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
-Original Message- From: Roland Dreier [mailto:[EMAIL PROTECTED] Sent: Friday, July 20, 2007 10:43 AM To: Nelson, Shannon Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Williams, Dan J; Leech, Christopher; Waskiewicz Jr, Peter P Subject: Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X are there any devices that support MSI but not MSI-X? If not, is there any point in having code to support both? - R. Both igb (recently posted) and ixgbe (also recently posted) support both MSI and MSI-X. Right now when we try to request MSI-X vectors, if we fail to acquire what we've asked for, we fall back to MSI support. If MSI fails to initialize, we fall back to legacy interrupts. So it needs to be there in case MSI-X allocation fails for the NIC driver. Thanks, -PJ Waskiewicz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Both igb (recently posted) and ixgbe (also recently posted) support both MSI and MSI-X. Right now when we try to request MSI-X vectors, if we fail to acquire what we've asked for, we fall back to MSI support. If MSI fails to initialize, we fall back to legacy interrupts. So it needs to be there in case MSI-X allocation fails for the NIC driver. Hmm, I see I don't understand what this driver is doing. What is a struct ioatdma_device? Is this driver requesting interrupts that come from the NIC or the IOAT DMA engine? Anyway, if the NICs support MSI-X, is there any chance of failing to get one MSI-X vectors but then succeeding in getting MSI enabled? How could that happen? I don't see what falling back to MSI buys you beyond more code. - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Hmm, I see I don't understand what this driver is doing. What is a struct ioatdma_device? Is this driver requesting interrupts that come from the NIC or the IOAT DMA engine? I might have caused some confusion. You had asked if any drivers support MSI but not MSI-X, so I threw 2 drivers out there that currently support both, and why we support MSI for compatibility. Anyway, if the NICs support MSI-X, is there any chance of failing to get one MSI-X vectors but then succeeding in getting MSI enabled? How could that happen? I don't see what falling back to MSI buys you beyond more code. MSI-X doesn't make much sense if you have 1 Rx queue on your NIC, since 1 vector essentially acts like MSI. In the case of why MSI-X could fail, I have had it fail when I misconfigured my driver and didn't ask for enough vectors for what I was assigning, so the driver disabled the multiple Rx queues, and fell back to MSI. I hope this helps. -PJ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Hmm, I see I don't understand what this driver is doing. What is a struct ioatdma_device? Is this driver requesting interrupts that come from the NIC or the IOAT DMA engine? I might have caused some confusion. You had asked if any drivers support MSI but not MSI-X, so I threw 2 drivers out there that currently support both, and why we support MSI for compatibility. Anyway, if the NICs support MSI-X, is there any chance of failing to get one MSI-X vectors but then succeeding in getting MSI enabled? How could that happen? I don't see what falling back to MSI buys you beyond more code. MSI-X doesn't make much sense if you have 1 Rx queue on your NIC, since 1 vector essentially acts like MSI. In the case of why MSI-X could fail, I have had it fail when I misconfigured my driver and didn't ask for enough vectors for what I was assigning, so the driver disabled the multiple Rx queues, and fell back to MSI. OK, let's try to avoid going off into the weeds here. In the context of the specific patch that this thread started with, is there any point in having both msix-single-vector and msi interrupt support? - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Roland Dreier wrote: OK, let's try to avoid going off into the weeds here. In the context of the specific patch that this thread started with, is there any point in having both msix-single-vector and msi interrupt support? This driver supports some chipsets that do MSI, and some that do MSI-X, but none that can do both. - Chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Roland Dreier [mailto:[EMAIL PROTECTED] OK, let's try to avoid going off into the weeds here. In the context of the specific patch that this thread started with, is there any point in having both msix-single-vector and msi interrupt support? Some versions of this hardware support MSI-X and not MSI. If it can't get all the MSI-X interrupts, it will try a single interrupt before fallign all the way down to Legacy interrupts. Basically, if we can only get one interrupt, we'd still like to use the MSI-X mechanics if possible. If totally out of the question, then we'll use legacy. sln -- == Mr. Shannon Nelson LAN Access Division, Intel Corp. [EMAIL PROTECTED]I don't speak for Intel (503) 712-7659Parents can't afford to be squeamish. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
This driver supports some chipsets that do MSI, and some that do MSI-X, but none that can do both. Thanks, that's the simple answer I was hoping for. Obviously if some chipsets only do MSI then you need the MSI code in addition to the MSI-X code. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
On 7/21/07, Roland Dreier [EMAIL PROTECTED] wrote: This driver supports some chipsets that do MSI, and some that do MSI-X, but none that can do both. Thanks, that's the simple answer I was hoping for. Obviously if some chipsets only do MSI then you need the MSI code in addition to the MSI-X code. In a case where you have a device that which supports MSI-X (multiple interrupts) but the device in default is in MSI mode, ie some configuration change is needed on the device. In such a case, how would one handle between MSI-X and MSI ? ie the device initially doesn't support MSI-X - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
In a case where you have a device that which supports MSI-X (multiple interrupts) but the device in default is in MSI mode, ie some configuration change is needed on the device. In such a case, how would one handle between MSI-X and MSI ? ie the device initially doesn't support MSI-X I don't understand the question really. Does the PCI spec even allow a device to be in MSI mode by default? Surely the OS must initialize the address/message before the device can generate an MSI? What device do you have in mind? I guess the interesting case is a PCIe device that supports MSI and MSI-X but not legacy interrupts. However I would assume such a device would come up with both MSI and MSI-X disabled. - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
On 7/21/07, Roland Dreier [EMAIL PROTECTED] wrote: In a case where you have a device that which supports MSI-X (multiple interrupts) but the device in default is in MSI mode, ie some configuration change is needed on the device. In such a case, how would one handle between MSI-X and MSI ? ie the device initially doesn't support MSI-X I don't understand the question really. Does the PCI spec even allow a device to be in MSI mode by default? Surely the OS must initialize the address/message before the device can generate an MSI? Sorry for being not clear. What i was asking is thus: A device that has legacy interrupts and MSI-X. I was thinking that if MSI-X failed one should fall back to MSI mode (single message), that's what i was assuming. In such a case, i do enable MSI-X mode on the device, when the request for 2 ^ n number of messages (where messages can be a max of 32), If the request fails one falls into a single message mode, ie MSI ? What device do you have in mind? The device that i have in mind is a SAA7160. I guess the interesting case is a PCIe device that supports MSI and MSI-X but not legacy interrupts. However I would assume such a device would come up with both MSI and MSI-X disabled. - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Manu Abraham [mailto:[EMAIL PROTECTED] Sorry for being not clear. What i was asking is thus: A device that has legacy interrupts and MSI-X. I was thinking that if MSI-X failed one should fall back to MSI mode (single message), that's what i was assuming. In such a case, i do enable MSI-X mode on the device, when the request for 2 ^ n number of messages (where messages can be a max of 32), If the request fails one falls into a single message mode, ie MSI ? What device do you have in mind? The device that i have in mind is a SAA7160. Notice our code looks at the return from pci_enable_msix() - it will give you a hint whether MSI-X is not supported (returns 0) or you simply asked for too many (returns 0). If the former, then fallback to legacy; if the latter, try MSI-X with only one interrupt, which essentially emulates MSI mode. sln -- == Mr. Shannon Nelson LAN Access Division, Intel Corp. [EMAIL PROTECTED]I don't speak for Intel (503) 712-7659Parents can't afford to be squeamish. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
On 7/21/07, Nelson, Shannon [EMAIL PROTECTED] wrote: Manu Abraham [mailto:[EMAIL PROTECTED] Sorry for being not clear. What i was asking is thus: A device that has legacy interrupts and MSI-X. I was thinking that if MSI-X failed one should fall back to MSI mode (single message), that's what i was assuming. In such a case, i do enable MSI-X mode on the device, when the request for 2 ^ n number of messages (where messages can be a max of 32), If the request fails one falls into a single message mode, ie MSI ? What device do you have in mind? The device that i have in mind is a SAA7160. Notice our code looks at the return from pci_enable_msix() - it will give you a hint whether MSI-X is not supported (returns 0) or you simply asked for too many (returns 0). If the former, then fallback to legacy; if the latter, try MSI-X with only one interrupt, which essentially emulates MSI mode. Ok. Thanks for clearing it up. So the idea would be that if pci_enable_msix() for n number of messages failed, then settle down for 1 message, which is equivalent to MSI mode - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Manu Abraham [mailto:[EMAIL PROTECTED] Ok. Thanks for clearing it up. So the idea would be that if pci_enable_msix() for n number of messages failed, then settle down for 1 message, which is equivalent to MSI mode yep - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
Ok. Thanks for clearing it up. So the idea would be that if pci_enable_msix() for n number of messages failed, then settle down for 1 message, which is equivalent to MSI mode And if that fails to acquire the one vector for whatever reason (MSI isn't enabled, or something is buggy in your chipset), fail back to legacy interrupts. Cheers, -PJ Waskiewicz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
From: Shannon Nelson <[EMAIL PROTECTED]> Date: Thu, 19 Jul 2007 17:45:12 -0700 > Add support for MSI and MSI-X interrupt handling, including the ability > to choose the desired interrupt method. > > Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]> Acked-by: David S. Miller <[EMAIL PROTECTED]> But: > +#define for_each_bit(bit, addr, size) \ > + for ((bit) = find_first_bit((addr), (size)); \ > + (bit) < (size); \ > + (bit) = find_next_bit((addr), (size), (bit) + 1)) This or something like it is codified in a few spots now, namely now here and cpumask.h, it would be nice to have this in some standard place. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
From: Shannon Nelson [EMAIL PROTECTED] Date: Thu, 19 Jul 2007 17:45:12 -0700 Add support for MSI and MSI-X interrupt handling, including the ability to choose the desired interrupt method. Signed-off-by: Shannon Nelson [EMAIL PROTECTED] Acked-by: David S. Miller [EMAIL PROTECTED] But: +#define for_each_bit(bit, addr, size) \ + for ((bit) = find_first_bit((addr), (size)); \ + (bit) (size); \ + (bit) = find_next_bit((addr), (size), (bit) + 1)) This or something like it is codified in a few spots now, namely now here and cpumask.h, it would be nice to have this in some standard place. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
