Interrupt Descriptions

[Jack Vogel]

What uses them, machines with multiqueue, in my ixgbe driver a rx/tx pair of
queues
is configured and bound to each cpu. This ability really matters when you do
virtualization
because the queues can be assigned per guest. So right now with 16 cpus a
single
Niantic or Oplin port (10G) has 33 MSIX vectors.

I brought this request to John because our validation group complained. On
Linux
they have a description for each interrupt and they want the same for
FreeBSD.

Welcome to the 21st century :)

Jack



On Thu, Oct 1, 2009 at 10:14 AM, Bruce Evans <brde at optusnet.com.au> wrote:

> On Thu, 1 Oct 2009, John Baldwin wrote:
>
>  On Wednesday 30 September 2009 8:02:57 pm Bruce Evans wrote:
>>
>>> On Wed, 30 Sep 2009, John Baldwin wrote:
>>>
>>>  A few folks have asked recently for the ability to add descriptive
>>>> strings to
>>>> registered interrupt handlers.  This is especially true since the advent
>>>> of
>>>> MSI with multiple interrupts per device.  I hacked up a prototype today
>>>> that
>>>>
>>>
>>> Interrupt names should be no longer than 4 (5 works sometimes) characters
>>> so
>>> that they can be displayed by systat -v.
>>>
>>
>> For the machines this is targeted at (i.e. ones with devices using
>> MSI/MSI-X)
>> the number of interrupts is already well beyond what systat -v can
>> currently
>> display anyway.
>>
>
> This should be fixed before expanding the names into descriptions.
>
> I wonder what uses all these interrupts.  Most FreeBSD cluster machines use
> a whole 3 interrupts apart from acpi_timer, with 1 barely active (1 disk,
> 1 net, and 1 serial i/o probably only used for a serial console).  My
> workstations use about 10 plus timers, but most are usually inactive
> except for net, keyboard and sometimes disk.  Does anyone have systems
> more than about 16 disk controllers and 16 network cards so as to need
> more than 32 interrupts?
>
>  I believe most folks use vmstat -i or ithread stats in top
>> to measure real-time interrupts at this point.  Possibly systat could grow
>> a
>> new interrupt-only mode that has sufficient room for full interrupt names.
>>
>
> I don't find static info and thus vmstat -i very useful.  vmstat with a
> repeat interval is useful, but for some reason vmstat -i never supported
> the repeat interval (its multi-line display is certainly unsuitable for
> repetitions being readable), and with systat -v repetition in vmstat -i
> is rarely missed.  A repeating vmstat -i would have even more space
> problems than systat -v, since it would want to repeat single line output.
>
> systat and most things just want a unique tag, not a description or even
> a full name.  The full name could be looked up from a tag by looking at
> vmstat -i output which could show both.
>
>
>> FYI, it actually looks decent enough running a 7.x systat on a test 9.0
>> kernel:
>>
>>                                    25000 frevn          pdpgs  2000 cpu0:
>> time
>>                                                         intrn
>> igb0:tx 0
>> Disks   da0 pass0                                  473896 wire     25
>> igb0:rx 0
>> KB/t   0.00  0.00                                   13872 act
>> igb0:link
>> tps       0     0                                   10080 inact
>> igb1:tx 0
>> MB/s   0.00  0.00                                     128 cache     1
>> igb1:rx 0
>> %busy     0     0                                 7603460 free
>>  igb1:link
>>
>> For these devices with MSI, the description (tx 0, tx 1, link, etc.) is
>> actually more meaningful than the IRQ.
>>
>
> The irq is probably least useful for most devices.
>
> The above is only reasonable because I changed systat to move "irqN:
> " to " irqN" at the end.  "irq256: bce0" on FreeBSD cluster machines
> is displayed reasonably as "bce0 256".  But systat shouldn't have to
> do this.  At least the form of the names used by systat (== the one
> given by the old intrnames API) should have names that are carefully
> phrased to have the most useful info first, and to not waste space
> with ": " or even "irq".
>
> Bruce
>
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>