Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Did you search the Internet or Cisco site using "interrupt" as one of your search terms?
Reason I ask, these forums are great for specific questions, such as your original question (to which, I believe, I've provided the answer), but more open ended questions, such an yours for unspecified elaboration, are often better explained reviewing the relevant documentation.
However, for a little more elaboration, interrupt CPU is where the Cisco device's (software based) frame/packet forwarding is ideally performed. I assume the term stems from doing this processing directly as part of an interrupt service routine, or as a process triggered by an interrupt (something like "kernal" mode processing).
Interrupt frame/packet forwarding is also sometimes referred to as "fast path" while non-interrupt frame/packet forwarding is also sometimes referred to as "process switching". Besides process switching, a device has many other routines running as scheduled processes.
On many ISRs, frame/packet forwarding is all performed by the main CPU, i.e. it's all software based, but interrupt switching has been written to be as efficient/optimal as possible. On such routers, its not unusual to find a 10x performance difference between interrupt switching and processing switching. (See attachment, for examples.)
