Re: RFC: MSI/MSI-X implementation

[David Young <dyoung%pobox.com@localhost>]

On Thu, Nov 13, 2014 at 01:59:09PM -0600, David Young wrote:
> On Thu, Nov 13, 2014 at 12:41:38PM +0900, Kengo NAKAHARA wrote:
> > (2014/11/13 11:54), David Young wrote:
> > >On Fri, Nov 07, 2014 at 04:41:55PM +0900, Kengo NAKAHARA wrote:
> > >>Could you comment the specification and implementation?
> > >
> > >The user should not be on the hook to set processor affinity for the
> > >interrupts.  That is more properly the responsibility of the designer
> > >and OS.
> > 
> > I wrote unclear explanation..., so please let me redescribe.
> > 
> > This MSI/MSI-X API *design* is independent from processor affinity.
> > The device dirvers can use MSI/MSI-X and processor affinity
> > independently of each other. In other words, legacy interrupts and
> > INTx interrupts can use processor affinity still. Furthermore,
> > MSI/MSI-X may or may not use processor affinity.
> 
> MSI/MSI-X is not half as useful as it ought to be if a driver's author
> cannot spread interrupt workload across the available CPUs.  If you
> don't mind, please share your processor affinity proposal and show how
> it works with interrupts.

Here are some cases that interest me:

1) What interrupts does a driver establish if the NIC has separate
   MSI/MSI-X interrupts for each of 4 Tx DMA rings and each of 4 Rx DMA
   rings, and there are 2 logical CPUs?  Can/does the driver provide
   any hints about the processor that is the target of each interrupt?
   What CPUs receive the interrupts?

2) Same as above, but what if there are 4 logical CPUs?

3) Same as previous, but what if there are 16 logical CPUs?

There's more than one way to crack this nut, I'm just wondering how you
propose to crack it. :-)

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981