Source: https://patents.google.com/patent/US8645596B2/en
Timestamp: 2018-05-21 19:34:01
Document Index: 43859524

Matched Legal Cases: ['Application No. 200610172499', 'Application No. 200610172499', 'Application No. 200610172499', 'Application No. 200610172499', 'Application No. 200610172499', 'Application No. 200980155570', 'Application No. 2011', 'Application No. 2011', 'Application No. 10', 'Application No. 096137538']

US8645596B2 - Interrupt techniques - Google Patents
Interrupt techniques Download PDF
US8645596B2
US8645596B2 US12319033 US31903308A US8645596B2 US 8645596 B2 US8645596 B2 US 8645596B2 US 12319033 US12319033 US 12319033 US 31903308 A US31903308 A US 31903308A US 8645596 B2 US8645596 B2 US 8645596B2
US12319033
US20100169528A1 (en )
The present application is related to U.S. patent application Ser. No. 12/319,099, filed Dec. 30, 2008, entitled “Message Communication Techniques”, now U.S. Pat. No. 7,996,548.
The subject matter disclosed herein relates generally to techniques for interrupting a processor.
In some cases, central processing units (CPUs) are used to process incoming network traffic. Accordingly, CPUs are required to process incoming traffic with low latency and real-time deadline guarantees. Polling input/output (I/O) and interrupt I/O are two major forms of interaction between a CPU and an I/O device. Polling I/O involves the CPU continuously querying the status of the I/O device while not doing any other work. Interrupt I/O involves use of interrupts to request CPU to respond to activity. It is desirable to develop techniques to request CPUs to perform tasks.
FIG. 14 depicts in block diagram format an example in which a message engine uses inter-processor interrupts (IPI) to interrupt a core, in accordance with an embodiment.
FIG. 15 depicts an example in which a message engine interrupts a core to request processing of a page fault, in accordance with an embodiment.
FIG. 16 depicts in block diagram format an example in which a message engine uses MSI-X interrupts to interrupt a core, in accordance with an embodiment.
FIG. 17 depicts an example in which a message engine ME interrupts a core using a dedicated, hardwired interrupt line, in accordance with an embodiment.
FIG. 18 depicts a process that can be used by a message engine to interrupt a core, in accordance with an embodiment.
Interrupts can be made by a message engine to one or more cores in response to a variety of circumstances. In some embodiments, a message engine associated with one or more cores interrupts the one or more cores using an inter-processor interrupt, MSI or MSI-x interrupt messages, or via a dedicated hardwired interrupt line. For example, interrupts can be made when received network traffic is available for processing. As another example, interrupts can be made in the event of a page fault in which a core or hardware thread is to respond to the page fault.
FIG. 4A depicts a simplified block diagram of a message engine in accordance with an embodiment. For example, message engine 400 can be used to transmit messages to any other message engine, such as a may be contained within a network interface. Message engine 400 can also be used to receive messages from another message engine. The network interface may be capable of transmitting and receiving network protocol units. As used herein, a “network protocol unit” may include any packet or frame or other format of information with a-header and payload portions formed in accordance with any protocol specification.
FIG. 9 depicts an example entry in a receive queue in accordance with an embodiment. Field Command (bits 7-0) is 0 for a Receive command. Field Immediate Interrupt (II), when set, directs the VME to generate a Co interrupt immediately, regardless of the interrupt moderation interval. Field Size specifies the number of bytes in contiguous virtual memory of the receive buffer. Upon completion of the message receive operation for this descriptor, the VMRE updates the Size field to contain the actual number of message segments received. Field Address specifies the virtual address in cacheable pageable memory of the receive buffer.
FIG. 10 depicts an example message segment format in accordance with an embodiment. Field RT specifies the Reassembly Tag returned in the CTS Messages. Field Destination VME Address specifies the destination VMRE for the segment. Field MSO specifies the Message Segment Offset of the segment. The MSO contains the position of this segment relative to the start of the message. The first segment of the entire message is numbered 0. The data portion of the segment contains the data payload of this segment. The length of the payload is Link Level specific. Although not depicted, the message segment format may also include a last field to indicate that a segment is the last segment of a message.
FIG. 14 depicts in block diagram format an example in which a message engine uses inter-processor interrupts (IPI) to interrupt a core. This example depicts the use of an IPI to inform a core (Core 1) to process incoming traffic (flow 1). Flow 1 arrives at a network interface 1402 and is transferred to memory 1406. The transfer may take place using a direct memory access engine (not depicted) and via an input/output (I/O) hub 1404. Core 1 is assigned to process flow 1. Message engine ME1 is associated with core 1 and a message engine associated with the network interface hub (shown as I/O ME) transmits data from network interface 1402 to message engine ME1 in the form of messages. Based on how Core 1 has configured message engine ME1, ME1 will decide when to interrupt Core 1 to inform Core 1 that flow 1 is available for processing.
In an embodiment, ME1 communicates the interrupt to core 1 via an inter-processor interrupt (IPI). Many central processing units (CPUs) have an interrupt command register (ICR). Message engine ME1 may trigger an IPI by writing to the ICR associated with a core to inform the core of the event. ME1 may generate IPIs at a rate set by an Extended Interrupt Throttle Register (EITR). EITR is a programmable register that specifies a rate of interrupts by ME1 to core 1. The EITR may be programmed by system software such as an operating system or driver. The rate of interrupts can be set to a low or high value depending on how much I/O traffic a core is already processing. The rate of interrupts can be set to a higher value if the core is processing a lower rate of I/O traffic. Conversely, the rate of interrupts can be set to a lower value if the core is processing a higher rate of I/O traffic.
Core 1 responds to the IPI by processing the I/O traffic and provides feedback to ME1 of future rate of interrupt by programming the interrupt rate in the EITR. Message engine ME1 uses the updated configuration to interrupt Core 1 for new messages at the specified rate.
Traditional network interface registers are not in the coherent domain because it may lead to high overhead on the memory management unit (MMU) to maintain coherency (i.e., send snoops and wait for responses) as well as because of bus traffic and delays. Uncoherent (UC) write instructions cannot be bypassed by other instructions and the network interface accessing the CPU takes a long time because there are multiple buses and bus controllers in between the network interface and CPU. In an embodiment, EITR is in the coherent domain and Core 1 can write to the EITR like any other memory address. Accordingly, Core 1 may access the EITR of ME1 much faster than other network interface registers that are not in the coherent domain.
The example of FIG. 14 can be extended to multiple cores, where each core uses an associated message engine to communicate with network interface 1402. For example, a second traffic flow may be associated with a second core, core 2 (not depicted). Each core can separately decide the rate of interrupts based on a data rate of I/O traffic the core receives from I/O device. A separate EITR in ME1 for each core or hyperthread may be used to allow interrupt rate control for each core or hyperthread.
FIG. 15 depicts an example in which a message engine interrupts a core to request processing of a page fault, in accordance with an embodiment. In this example, transfer of a segment N to memory incurs a page fault. At the time the I/O ME 1502 tries virtual to physical memory translation for a transfer to memory, I/O ME 1502 may detect a page fault. A page fault may occur when the I/O ME 1502 attempts to access a page that is mapped in address space, but not loaded in physical memory. I/O message engine 1502 may transmit a message to notify the message engine associated with core 1508 (shown as core ME 1504) of the page fault for the transfer of segment N. Core ME 1504 may issue an IPI to indicate a queue number (QN), message sequence number (MSN), and message segment offset (MSO) that are associated with the page fault. A controlling fault handler 1506 for a virtual memory layer associated with core 1508 may process the IPI. If the page fault is in user virtual memory, then a kernel fault handler may be invoked. However, if the page fault is in guest physical memory, then the hypervisor may be invoked to remedy the page fault.
Core 1508 may issue commands to the IO device via core ME 1504. For example, core 1508 may request transmission of commands using messages from core ME 1504 to I/O ME 1502 to request I/O ME 1502 to stop transmitting messages that would also trigger a page fault. After a page fault is corrected, core 1508 may transmit messages via core ME 1504 to I/O ME 1502 to request message re-transmission.
FIG. 16 depicts in block diagram format an example in which a message engine uses MSI-X interrupts to interrupt a core, in accordance with an embodiment. In this example, core 1 is assigned to process incoming network traffic from network interface 1402, which is identified as flow 1. Message engine ME1 is assigned to core 1. Flow 1 is transferred into memory 1602 in a similar manner as that of flow 1 of FIG. 14. In this embodiment, message engine ME1 includes an MSIx message builder 1604 that is capable of generating a message signaled interrupts (MSI) or MSI-X type interrupts. MSI-X is described in the PCI Express Base Specification 1.0a (2003). Queue monitor 1603 of message engine ME1 monitors the fullness of the queue assigned to store flow 1. When the queue is underflown, ME1 interrupts core 1 by writing to the MSI-X memory region and requests processing of I/O traffic. Core 1 uses a programmable interrupt controller (APIC) to monitor changes to the MSI-X memory. Core 1 responds to interrupts generated by the MSI-X mechanism.
FIG. 17 depicts an example in which a message engine ME interrupts a core using a dedicated, hardwired interrupt line (shown as INT-A), in accordance with an embodiment. Interrupt line INT-A may be implemented in a similar manner as interrupt lines in Industry Standard Architecture (ISA) buses.
FIG. 18 depicts a process 1800 that can be used by a message engine to interrupt a core, in accordance with an embodiment. Block 1801 may include a message engine being notified via messages of activity that is to be processed by a core. For example, the interrupt may notify the core that network traffic is available for processing. For example, the interrupt may notify the core to correct a page fault.
Block 1802 may include the message engine informing the core of the activity via an interrupt. The interrupt may be made via an IPI, MSI, MSI-X, or dedicated hardwired interrupt line. A rate at which the message engine may interrupt the core can be specified by the core by writing to a register in the coherent memory domain.
Block 1803 may include the core responding to the interrupt. For example, the core may respond by processing received network traffic or remedying a page fault. Although, a variety of other tasks may be performed by the core.
receiving contents of a network protocol unit from one or more message segments at a buffer identified by a queue associated with a virtual message receive engine, wherein the virtual message receive engine is associated with a message engine and wherein identification of a memory address of the buffer comprises identification of a virtual message engine address of the message engine and is independent of identifying a destination memory address of the buffer, wherein at least one of the message segments comprises:
a reassembly tag field; and
a message segment offset field, wherein
the queue is based at least in part on the reassembly tag field,
the buffer is located based at least in part on the reassembly tag field, and
a location in the buffer to store at least one of the message segments is based at least in part on the message segment offset field; and
indicating availability of contents of the buffer to a core using an interrupt.
2. The method of claim 1, wherein the indicating availability of contents of the buffer from the message engine to a core using an interrupt comprises generating an inter-processor interrupt.
3. The method of claim 1, wherein the indicating availability of contents of the buffer from the message engine to a core using an interrupt comprises writing an MSI-X message in an MSI-X memory region.
the core programming a rate at which the message engine can interrupt the core.
5. The method of claim 4, wherein the core programming a rate comprises the core writing to a register in a coherent memory domain.
7. The method of claim 1, wherein at least one of the message segments comprises:
receiving an indication of a page fault in response to attempting to write contents of the one or more message segments to the buffer; and
indicating the page fault to the core using a second interrupt.
receiving a second network protocol unit;
transmitting contents of the second network protocol unit using one or more message segments to a second buffer associated with a second message engine; and
indicating availability of contents of the second buffer to a second core using a second interrupt.
a memory configured to store a buffer to receive contents of a network protocol unit from one or more message segments;
a message engine to indicate availability of the contents of the buffer to the core using an interrupt, wherein the message engine is configured to associate with a virtual message receive engine and wherein identification of a memory address of the buffer includes identification of a virtual message engine address of the virtual message receive engine and is independent of identification of a destination memory address of the buffer, wherein at least one of the message segments comprises:
a queue is based at least in part on the reassembly tag field,
the buffer is identified using the queue and is located based at least in part on the reassembly tag field, and
a location in the buffer to store at least one of the message segments is based at least in part on the message segment offset field.
11. The apparatus of claim 10, wherein to indicate availability of contents of the buffer from the message engine to the core, the message engine is to generate an inter-processor interrupt.
12. The apparatus of claim 10, wherein to indicate availability of contents of the buffer from the message engine to the core, the message engine is to write an MSI-X message in an MSI-X memory region.
13. The apparatus of claim 10, wherein the core is to program a rate at which the message engine is permitted to interrupt the core.
14. The apparatus of claim 13, wherein to program a rate at which the message engine is permitted to interrupt the core, the core is to write to a register in a coherent memory domain.
15. The apparatus of claim 10, wherein at least one of the message segments comprises:
a second buffer, wherein:
in response to receipt of an indication of a page fault in response to an attempt to write contents of the one or more message segments to the second buffer, the message engine is to indicate the page fault to the core using an interrupt.
a second buffer to receive contents of a network protocol unit from one or more message segments, wherein to indicate availability of contents of the second buffer to the core, the message engine is to generate one or more of an inter-processor interrupt and an MSI-X message.
18. The apparatus of claim 10, wherein the core is to regulate the rate at which the core is to receive interrupts.
a network interface to receive a network protocol unit; and
first and second message engines, wherein
the first message engine is to form at least one message from contents of the network protocol unit and to transmit the at least one message to a buffer accessible to the second message engine, wherein a virtual message receive engine is configured to associate with the second message engine and wherein to transmit to the buffer, the first message engine is to identify a memory address of the buffer using a virtual message engine address of the virtual message receive engine independent of identification of the destination memory address of the buffer, wherein at least one message comprises:
a location in the buffer to store at least one of the message segments is based at least in part on the message segment offset field, and
the second message engine is to notify one of the at least one core of availability of the message using an interrupt.
20. The system of claim 19, wherein to notify one of the at least one core of availability of the message using an interrupt, the second message engine is to generate one or more of an inter-processor interrupt and an MSI-X message.
21. The system of claim 19, wherein at least one core is to program a rate at which the second message engine is to generate interrupts.
22. The system of claim 19, wherein the first message engine comprises:
a message mapper to determine a destination virtual message receive engine associated with the network protocol unit; and
logic to transmit content of the network protocol unit using at least one message to a buffer associated with the destination virtual message receive engine.
23. The system of claim 19, wherein the first message engine is to form at least one segment from the at least one message.
24. The system of claim 19, wherein at least one message further comprises:
a link layer and
25. The method of claim 8, wherein the second interrupt comprises one or more of an inter-processor interrupt and an MSI-X message.
US12319033 2008-12-30 2008-12-30 Interrupt techniques Active 2030-06-15 US8645596B2 (en)
US12319033 US8645596B2 (en) 2008-12-30 2008-12-30 Interrupt techniques
PCT/US2009/068425 WO2010078017A3 (en) 2008-12-30 2009-12-17 Interrupt techniques
US20100169528A1 true US20100169528A1 (en) 2010-07-01
US8645596B2 true US8645596B2 (en) 2014-02-04
ID=42286270
US12319033 Active 2030-06-15 US8645596B2 (en) 2008-12-30 2008-12-30 Interrupt techniques
US (1) US8645596B2 (en)
WO (1) WO2010078017A3 (en)
US8631181B2 (en) * 2011-09-26 2014-01-14 Oracle International Corporation Validating message-signaled interrupts by tracking interrupt vectors assigned to devices
US20140156894A1 (en) * 2012-11-30 2014-06-05 Red Hat Israel, Ltd. Msi events using dynamic memory monitoring
US9830286B2 (en) * 2013-02-14 2017-11-28 Red Hat Israel, Ltd. Event signaling in virtualized systems
US9544261B2 (en) * 2013-08-27 2017-01-10 International Business Machines Corporation Data communications in a distributed computing environment
US20170285717A1 (en) * 2016-03-31 2017-10-05 Intel Corporation Method and apparatus to improve energy efficiency of parallel tasks
JPH07177164A (en) 1993-12-20 1995-07-14 Fujitsu Ltd Frame communication equipment
US5758169A (en) 1990-12-21 1998-05-26 Intel Corporation Protocol for interrupt bus arbitration in a multi-processor system
JPH11249978A (en) 1998-03-04 1999-09-17 Nippon Telegr & Teleph Corp <Ntt> Method and device for transferring data
JP2002305535A (en) 2001-01-11 2002-10-18 Internatl Business Mach Corp <Ibm> Method and apparatus for providing a reliable protocol for transferring data
JP2004531001A (en) 2001-06-29 2004-10-07 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｓｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ Data transfer between the host computer system and Ethernet (r) · Adapter
US20050027914A1 (en) 2003-07-31 2005-02-03 Per Hammalund Inter-processor interrupts
US20050132210A1 (en) 2003-08-01 2005-06-16 Mamoon Yunus Hybrid Java-C network appliance
US20050238019A1 (en) 2004-03-31 2005-10-27 Intel Corporation Techniques to control access to logic
US20060007855A1 (en) 2004-07-07 2006-01-12 Tran Hieu T Prioritization of network traffic
JP2006516054A (en) 2002-06-11 2006-06-15 アシシュ エイ パンドヤ High-performance ip processor for the Tcp / ip, rdma, and ip storage applications
US7212528B2 (en) 2001-12-21 2007-05-01 Alcatel Canada Inc. System and method for reassembling packets in a network element
US20070168580A1 (en) 2006-01-18 2007-07-19 Frederic Schumacher Apparatus to improve the firmware efficiency for a multiframe serial interface
CN101004728A (en) 2006-01-06 2007-07-25 惠普开发有限公司 DMA access systems and methods
US20080059686A1 (en) 2006-08-31 2008-03-06 Keith Iain Wilkinson Multiple context single logic virtual host channel adapter supporting multiple transport protocols
US20080080491A1 (en) 2006-09-29 2008-04-03 Ramakrishna Saripalli Methods for pushing address translations mappings to PCI express endpoints
WO2008045809A2 (en) 2006-10-06 2008-04-17 Intel Corporation Network interface techniques
US20090213732A1 (en) 2008-02-27 2009-08-27 Bryan Veal Preserving packet order when migrating network flows between cores
US20100070677A1 (en) 2008-09-15 2010-03-18 Vmware, Inc. System and Method for Reducing Communication Overhead Between Network Interface Controllers and Virtual Machines
US20100169501A1 (en) 2008-12-30 2010-07-01 Steven King Massage communication techniques
US20100169528A1 (en) 2008-12-30 2010-07-01 Amit Kumar Interrupt technicques
US20100262743A1 (en) 2009-04-08 2010-10-14 Zimmer Vincent J System management mode inter-processor interrupt redirection
CN1578263A (en) 2003-06-27 2005-02-09 英特尔公司 Method and system for a network node for attachment to switch fabrics
US7525967B2 (en) 2004-03-31 2009-04-28 Intel Corporation Techniques to control access to logic
WO2010078017A2 (en) 2008-12-30 2010-07-08 Intel Corporation Interrupt techniques
WO2010078010A2 (en) 2008-12-30 2010-07-08 Intel Corporation Message communication techniques
"IBM System x Advanced Networking Features", May 2006, 12 pages.
"M3F2-PCIXE-2, M3F2-PCIXE-4 ("E card")", Two-Port Myrinet-Fiber/PCI-X Network Interface Card (NIC),Myricorn, Dec. 28, 2005, 2 pages.
Bush, Stephen F., "Active Virtual Network Management Prediction", In Parallel and Discrete Event Simulation Conference (PADS) 1999, 13 Pages.
Bush, Stephen F., "Active Virtual Network Management Protocol", General Electric Corporate Research and Development, Niskayuna, NY, 1999, 11 Pages.
Cramer, "[RFC] Asynchronous IPI and e1000 Multiple Queues", Sep. 23, 2005, 2 pages, Available at: https://Ikml.org/Ikml/2005/9/23/204.
Foong et al., "An Architecture for Software-Based iSCSI: Experiences and Analyses", Lecture Notes in Computer Science: Networking 2005, vol. 3462/2005, pp. 1-12.
Gupta et al., "Boosting Data Transfer with TCP Offload Engine Technology on Ninth-Generation Dell PowerEdge Servers", Dell Power Solutions, Aug. 2006, pp. 18-22.
Intel, "Improving Network Performance in Multi-Core Systems", White Paper, Intel Ethernet Controllers, 2007, 4 pages.
International Preliminary Report on Patentability received for PCT Patent Application No. PCT/US2007/080633, mailed on Apr. 16, 2009, 7 pages.
International Preliminary Report on Patentability received for PCT Patent Application No. PCT/US2009/068396, mailed on Jul. 14, 2011, 5 pages.
International Preliminary Report on Patentability received for PCT Patent Application No. PCT/US2009/068425, mailed on Jul. 14, 2011, 6 pages.
International Search Report and Written Opinion for PCT Patent Application No. PCT/US2009/068396, mailed on Jul. 28, 2010, 9 Pages.
International Search Report and Written Opinion for PCT Patent Application No. PCT/US2009/068425, mailed on Jun. 29, 2010, 11 pages.
International Search Report and Written Opinion received for PCT Patent Application No. PCT/US2007/080633, mailed on Mar. 31, 2008, 10 pages.
Mattern, Friedemann, "Efficient Algorithms for Distributed Snapshots and Global Virtual Time Approximation", Journal of Parallel and Distributed Computing, 1993, vol. 18, No. 4, Germany, pp. 1-20.
Muir et al., "AsyMOS-An Asymmetric Muitiprocessor Operating System", In Proceedings of OPENARCH '98, Apr. 1998, pp. 1-10.
Muir et al., "AsyMOS—An Asymmetric Muitiprocessor Operating System", In Proceedings of OPENARCH '98, Apr. 1998, pp. 1-10.
office Action Received for Chinese Patent Application No. 200610172499.X, issued on Jan. 22, 2010, 7 Pages Chinese Office Action including 3 pages of English Translation.
Office Action Received for Chinese Patent Application No. 200610172499.X, mailed on Jan. 27, 2011, 6 pages of English Translation and 4 pages of Office Action.
Office Action Received for Chinese Patent Application No. 200610172499.X, mailed on Mar. 5, 2013, 5 pages of English Translation and 3 pages of Office Action.
Office Action Received for Chinese Patent Application No. 200610172499.X, mailed on Mar. 9, 2012, 5 pages of English Translation and 3 pages of Office Action.
Office Action Received for Chinese Patent Application No. 200610172499.X, mailed on Nov. 5, 2012, 13 pages of English Translation and 6 pages of Office Action.
Office Action Received for Chinese Patent Application No. 200980155570.5 mailed on Sep. 24, 2013, 18 pages of English Translation and 14 pages of Office Action.
Office Action Received for Japanese Patent Application No. 2011-543585, mailed on Mar. 26, 2013, 1 page of English Translation and 1 page of Office Action.
Office Action Received for Japanese Patent Application No. 2011-543585, mailed on Nov. 27, 2012, 2 pages of English Translation and 2 pages of Office Action.
Office Action Received for Korean Patent Application No. 10-2011-7017993, mailed on Jan. 23, 2013, 3 pages of English Translation and 4 pages of Office Action.
Office Action Received for Taiwanese Patent Application No. 096137538, mailed on Dec. 26, 2011, 4 pages of English Translation and 8 pages of Office Action.
Office Action received for U.S. Appl. No. 11/539,510, mailed on Feb. 25, 2011, 25 pages.
Office Action received for U.S. Appl. No. 11/539,510, mailed on Mar. 26, 2010, 24 pages.
Office Action received for U.S. Appl. No. 11/539,510, mailed on Sep. 8, 2010, 21 pages.
Office Action received for U.S. Appl. No. 12/319,099, mailed on Oct. 4, 2010, 28 Pages of Office Action.
Office Action received for U.S. Appl. No. 13/173,459, mailed on Sep. 23, 2011, 10 pages.
Office Action received for U.S. Appl. No. 13/662,989, mailed on Mar. 5, 2013, 24 pages.
Romanow, Allyn et al., "An Overview of RDMA over IP", In First International Workshop on Protocols for Fast Long-Distance Networks, 2003, pp. 1-22.
Shafer et al., "A Gigabit Reconfigurable Programmable Network Interface Card", Department of Electrical and Computer Engineering, Rice University, 2005, pp. 1-14.
Shah, Hemal et al., "Direct Data Placement over Reliable Transports (Version 1.0)", draft-shah-iwarp-ddp-v1.0, Oct. 21, 2002, pp. 1-35.
Veal et al., "Performance Scalability of a Multi-Core Web Server", Proceedings of the 3rd ACM/IEEE Symposium on Architecture for networking and communications systems, Dec. 3-4, 2007, pp. 57-66.
WO2010078017A3 (en) 2010-08-26 application
US20100169528A1 (en) 2010-07-01 application
WO2010078017A2 (en) 2010-07-08 application
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KUMAR, AMIT;KING, STEVEN;HUGGAHALLI, RAM;AND OTHERS;SIGNING DATES FROM 20080319 TO 20090320;REEL/FRAME:026599/0587