Roamer since this is a full case now, the procedure is to add the
comments to the issues file (for internal contributors).
Kais.
On 10/10/08 19:14, Yunsong (Roamer) Lu wrote:
> A few more concerns about the IRM proposed interfaces.
>
> 1. When the material talks about current interface limitation, 4.1.2,
> why it's a problem to allow a driver to get more that *2* MSI-X? Those
> integrated device drivers should be prepared that it can not get any
> MSI-X interrupt vector, and it might try the legacy INTX instead. So
> it should not be a problem even all MSI-X vectors have been given to
> those attached drivers. Late-attached drivers will just use legacy
> INTX interrupts. The justification for current *hard-coded* limitation
> doesn't make sense.
>
> 2. How the IRM framework decide to decrease the number of interrupt
> vectors that have been given to a driver? 4.2.1 talk about how driver
> participate the IRM interfaces, but it's obscure how the framework can
> wisely move interrupt resources around drivers.
>
> 3. How the IRM framework make *wise* decision about which driver can
> take more interrupt vectors than others? For example, when you have a
> 10GbE NIC and a 1GbE NIC in the box, both drivers ask for 16 vectors
> when you don't have enough vectors left. To give the same amount of
> interrupt vectors to two driver instances are unreasonable. As part of
> Crossbow project, hardware resources are allocated depending on the
> real link speed and bandwidth need. But as the low level I/O
> framework, IRM don't have knowledge about those information. How do
> you prove that your "management" is reasonable?
>
> 4. What's the perimeter of IRM? In a virtualized environment,
> interrupts might have been bound to CPUs in an exclusive zone or a
> guest domain, when IRM asks such interrupt vectors back from the
> driver, who will take care of the interrupt re-targeting? It's out of
> driver's control, and I can not find any relevant information from
> this document.
>
> Thanks,
>
> Roamer
