we now discuss a shortcoming with the approach described in the background for handling layer - 2 network traffic destined for multiple guest - functions or multiple instances of guest - os &# 39 ; s operating on a host computer executing on top of a virtualization layer ( also called virtual operating system ( vos ) when multiple instances of guest - os &# 39 ; s are present ). the “ guest function ” corresponds to a particular protocol stack instance . this can for example refer to the tcp / ip networking stack , and the scsi storage stack used or usable from within the same instance of a guest - os . in this case the tcp / ip networking stack would represent one “ guest function ” and the scsi storage stack another “ guest function ”. this is just one example of the usage of multiple “ guest functions ” within a particular instance of a “ guest os .” in a case where there is only one protocol stack used or usable from within an instance of a guest - os , then the instance of the guest - os is considered to have a single guest - function associated with it , which is the instance of the guest - os itself . in addition , it should be noted that some or all of the instances of guest - os &# 39 ; s may be separate instances of the same os , such as , for example , windows or linux . in particular , the approach described in the background places a computational load on the virtualization layer or vos to demultiplex the network traffic , and this load can be quite substantial for high - speed network interfaces . another shortcoming is the overhead associated with copying data from memory associated with the virtualization layer or vos to memory associated with the destination guest - functions or instances of guest - os &# 39 ; s in all cases for ingress packets , and copying data from memory associated with a particular origin guest - os instance to memory associated with the vos in the egress direction . it is thus desirable to reduce the computational load and overhead on the virtualization layer or vos associated with processing ingress packets destined to multiple guest functions or instances of guest os &# 39 ; s . it is also desirable to protect against each guest - function or guest - os instance corrupting data structures for packet ingress associated with the other guest - functions or guest - os &# 39 ; s . conventionally , data structures for direct memory access ( dma ) such as command queues , free - list pages , and completion queues are shared for network traffic destined to the multiple guest - functions and instances of guest - os &# 39 ; s , and memory corruption by one guest - os instance thus necessarily affects the other guest - functions and instances of guest - os &# 39 ; s . in the remainder of this discussion , we will consider the example where multiple instances of os &# 39 ; s are running atop a vos . a similar discussion applies to the case where multiple functions are supported atop a virtualization layer or a combination of multiple functions and multiple instances of os &# 39 ; s are in use . specifically , referring now to fig1 , it is desirable to be able to virtualize the network interface circuitry that provides an interface between a network 102 and a host computer 105 , where the host computer 105 has a single virtual operating system ( vos ) 100 with multiple guest operating systems ( instances of guest - os &# 39 ; s 110 , 120 , 130 ) executing on top of the vos 100 . the vos 100 may be , for example , a virtual operating system such as provided by xen or vmware . in particular , each guest - os instances interacts with the single nic 150 as if the single nic 150 were a private nic , not shared with the other instances of guest os &# 39 ; s . in fig1 , three instances of guest os &# 39 ; s are shown as an example , but a vos can in principle have any number of instances of guest - os &# 39 ; s executing on top of it . in accordance with one aspect described here , the promiscuous mode of the mac ( described in the background ) is not used . in accordance with another aspect , memory references resulting from network traffic originating from , and destined to , each guest - os instance is segregated from memory references resulting from network traffic from / to the other instances of guest os &# 39 ; s . having the nic not be in promiscuous mode has an advantage of decreasing the ingress packet traffic ( between the nic and the host ) and thereby minimizing or eliminating the overhead of the host processing packets not destined for any of the instances of guest - os &# 39 ; s . memory reference safety may be accomplished , for example , by segregating the dma command queues , gather - lists , free - lists , and completion queues used by each guest - os instance . copying and delivery of multicast and broadcast network traffic to the instances of guest os &# 39 ; s can optionally be handled or assisted by the nic , so that all the processing of network traffic is offloaded to the nic . in addition , direct data placement ( ddp ) can be accomplished safely by having the vos validate the creation of the ddp regions by the instances of guest - os &# 39 ; s . as mentioned above , each of the instances of guest - os &# 39 ; s uses a separate data structure for dma transfers ( e . g ., referred to here as command queue 200 , gather - list 210 , free list 220 , direct - data region 230 , and response queue 240 ). fig1 illustrates an example in which the data structures used for such dma reside within different non - overlapping memory regions , but this is not necessarily required . we first discuss the egress ( host to network ) data path . referring specifically to fig1 , for egress data , commands are placed in the command queue 200 for a particular guest - os instance , indicating that payload data is to be dma read from the corresponding dma gather - list 210 . the command queue 200 itself is dma read by the nic 150 . the nic 150 writes to the particular response queue 240 for the guest - os instance when a command has been completed , thus providing the host an update on the progress of the execution of the dma commands . for the ingress ( network to host ) data path , the nic 150 either directly writes payload data into the direct data 230 region for the destination guest - os instance , or writes payload data to the scatter - list 220 for the guest - os instance indicated in one or more entries of the scatter - list 220 for the guest - os instance . in the direct data 230 case , placement information ( i . e ., mapping ) for the guest - os is previously communicated to the nic 150 , for example as part of setting up a remote dma transfer or to enable direct data placement of socket api read ( ) response data . in the free list case , the location of the scatter - list pages for the guest - os instance has been previously communicated to the nic 150 , e . g ., via dma reads . finally , the response queue 240 for the guest - os instance is typically also written for ingress transfers for the guest - os instance to indicate that a particular entry has been placed in either a free - list 220 entry or entries , or that payload data has been directly placed in the direct data 230 region for the guest - os instance . in some examples , the nic 150 is configured to offload protocol processing for some protocols . for example , the nic 150 may have capability to offload processing for the tcp protocol . in another example , as previously noted , the nic 150 may have capability to offload protocols at layers above tcp , such as iscsi and nfs . as a result of the virtualization capabilities of the nic 150 , the memory references due to egress network traffic originating from a particular guest - os instance are segregated in one or more command queues 200 , and one or more gather - list 210 data structures on the host computer may also be segregated within the nic . in addition , segregated response queues 240 may be used . in some examples , the egress traffic is segregated within the nic by mapping packets from a particular guest - os instance to particular queues within an egress packet scheduler within the nic . however , in some examples , the egress packet traffic corresponding to different instances of guest - os &# 39 ; s is interleaved through the nic . furthermore , the virtualization configuration of the nic 150 is such that memory references due to ingress network traffic arriving at the nic from the network are segregated within the nic 150 , and are steered to separate segregated scatter - lists 220 , direct data region 230 , and response queue 240 , corresponding to a particular guest - os instance 110 120 130 . in sum , the just - described mode of mode of operation is referred to by us as multiple guest - functions or instances of guest - os &# 39 ; s running securely on top of a virtualized nic . for example , multiple instances of windows or linux may be running on top of a vos such as provided by vmware or xen . in another example , iscsi , rdma and tcp / ip sockets may be running on top of a virtualization layer . each instance of the guest - function and guest - os broadly sees itself running on its own ( virtual ) nic , while in effect it is running along with other functions and instances of guest os &# 39 ; s on top of a single virtualized nic . the operation is referred to as “ secure ” because each guest - function and guest - os instance has its own data structures in the host memory and one guest - function or guest - os instance therefore will not corrupt the memory associated with the operation of the other guest - function and guest - os instances . because the different guest - functions and instances of guest - os &# 39 ; s use different data structures , a particular guest function or guest - os instance does not have access permission to the physical memory in use by the other guest functions and instances of guest - os &# 39 ; s . having generally described virtualization of a nic , we now describe three specific approaches to achieving virtualization of a nic . in accordance with the first approach , the virtual nic &# 39 ; s are operated in what is referred to as “ promiscuous mode ,” such that all ingress ethernet packets are forwarded to the virtualization layer or vos . for example , an incoming packet with a destination mac address that does not match any of the local mac addresses will not be dropped . instead , the incoming packet will reach the virtualization layer or vos . the virtualization layer or vos may then make a decision to drop packets that have destination mac addresses not corresponding to any of the guest - functions and instances of guest - os &# 39 ; s and also drop packets with a matching destination mac address but a non - matching destination ip address . the virtualization layer or vos also processes broadcast and multicast packets . note that the guest functions and instances of guest - os &# 39 ; s may or may not utilize the same local mac address . in contrast to the first approach , the second approach employs destination address filtering in the nic , such that only those packets having an address corresponding to one of the guest - os &# 39 ; s are accepted by the nic and forwarded to the vos . the multicast packets are typically also filtered , and a packet that is not destined for any of the instances of guest - os &# 39 ; s is dropped . the broadcast packets are typically delivered to all guest functions and instances of guest - os &# 39 ; s . note that the destination address used in this method may be the mac address or the ip address . therefore , the virtualization layer or vos matches the local mac or internet protocol address ( lip ) for the guest functions or instances of guest - os &# 39 ; s in this approach and processes broadcast and multicast packets . the third approach also employs destination address filters , but uses an indirection - map to map the matching packets to a guest - function or guest - os instance via an index ( sometimes referred to in this description as the “ guest_idx ” and / or “ steering index ”). for example , the mac address of an ingress ethernet packet is matched to a guest_idx using a lookup table . if the packet encapsulates an ip packet , the destination ip address in the ip packet is then compared to the ip address ( one or more ) associated with the particular guest - os instance having the particular mac address index ( guest_idx steering index ). packets that do not have a valid ( guest_idx , lip ) tuple are dropped in the nic . in this third approach , filtering is achieved by parsing the ethernet packets and applying a filtering rule associated with the guest_idx ( that is part of the tuple that indicates if the packet should be accepted or dropped ). in a nic that implements protocol offload , this approach accommodates offloaded protocols by adding the guest_idx to the tuple that typically includes the 4 - tuple ( lip , lp , fip , fp ) for either the tcp or udp protocols . as an example , the resulting 5 - tuple would be used as an identifier of a particular tcp connection or udp stream . a step in the virtualization with this third approach employs the guest_idx steering index to steer the incoming packet directly , without the intervention of the virtualization layer or vos , to the appropriate destination guest - function or guest - os instance . for this purpose , the nic uses the guest_idx steering index , optionally along with other fields of the packet or other pertinent information or criteria , to select a queue triplet ( e . g ., send - queue / response - queue / completion - queues for rdma / iwarp traffic , or command - queue / free - list - queue / response - queue for other traffic ) corresponding to the appropriate guest - function or guest - os instance . the selection step may further involve the determination of a particular cpu number on which the received packet is to be processed . using a target cpu number , the packet processing load may be distributed among potentially multiple cpus on the system . two options with this third approach are now described to process multicast and broadcast packets . the distribution of these packets can either be performed by the nic that receives the multicast and broadcast traffic or , alternately , these packets can be sent to the virtualization layer or vos for processing . with the latter alternative , the packets may be mapped to one or more specific command - queue / free - list - queue / response - queue triplets , which facilitates processing of the packets by the virtualization layer or vos . a benefit of the first option is that broadcast and multicast packets may be processed without involvement of the virtualization layer or vos , but this is at the cost of multiple copies of the packet being provided over the host ( e . g ., pci ) bus . a decision as to which option to utilize may be based , for example , on a particular context and usage scenario . in one example for processing multicast ethernet packets , the ethernet destination address is provided as input to a hashing function , the result of which is used to determine if the packet is to be accepted or dropped by the nic . the result of the multicast address hash is compared to the allowed hash values , which are provided to the nic by the virtualization layer or vos on behalf of the guest functions or instances of guest - os &# 39 ; s . this results in a partial ( imperfect ) filtering of undesired multicast traffic , since the filtering criterion is not exact . in other words , the exact mac address matching criteria is replaced by a hash of the multicast , and if a match to a hash table is produced within the ethernet media access control block of the nic , the packet is accepted . the packet may then be multicast / broadcast to the different guest - functions and guest - os &# 39 ; s by an on - chip module that has stored a table with information about which guest - function or guest - os subscribes to which multicast . the nic can , based on this determination , either multicast the packet to the appropriate guest functions or instances of guest - os &# 39 ; s , or deliver the packet to the virtualization layer or vos that performs the multicast / broadcast , possibly based on an indication of this determination provided by the nic along with the packet . a guest function or os may be configured to operate its virtual nic ( s ) in promiscuous mode , while other virtual nic &# 39 ; s are independently configurable . promiscuous mode operation may be useful in certain circumstances , such as for troubleshooting network problems . it is therefore useful for the nic to support the promiscuous mode operation on a per - virtual nic basis . in this case , the nic can relax the filtering rule used for the particular guest - os instance that is configured to operate the virtual nic in this mode . as a result , the particular guest - function or guest - os instance is provided with copies of all the packets received , even those that are determined to be destined to other guest - functions and instances of guest - os &# 39 ; s , regardless of the destination mac address . fig2 broadly illustrates an implementation of the virtualization capability for the ingress path within the processing pipeline of a nic . a data source 50 is a source of packets received from the network . for example , the data source 50 may be a peer on a 10 gbps ethernet network . an ethernet destination address filtering lookup device 52 looks up in a filtering rule database the steering index ( guest_idx ) corresponding to the matching 48 - bit ethernet local address . when there is no matching entry , the packet is dropped unless the device is operating in promiscuous mode , for example on behalf of one of the instances of guest os &# 39 ; s . the mac address is 48 - bits wide for ethernet , and the size of the index is at least the logarithm of the maximum number of supported addresses in the filtering database . for example if 65536 , 1024 , 256 , or 8 addresses are the maximum number of supported addresses in the database , the size of the index is at least 16 bits wide , 10 bits , 8 bits , and 3 bits wide , respectively . in some examples , for efficiency reasons , the steering index is used within the processing path rather than the mac address itself . the steering index , described below , is used within the processing path to steer a packet 54 to the correct dma scatter - list , and response queue . if the packet is indicated as being multicast , then it may be handled as discussed above ( according to a hash table ). turning now to fig3 , a flow processor architecture of the interface device 100 , having an ingress virtualization capability , is described . an arbiter 102 arbitrates among various signals such as headers of control messages from a host ( 104 a ), data packets from the physical wire of the network ( 104 b ), transmission modulation event tokens ( 104 c ), and receive modulation event tokens ( 104 d ). the transmission modulation event tokens are associated with the transmission scheduler , and the receive modulation event tokens with the receive scheduler , respectively . it is noted that the arbiter 102 is a feature of the particular flow processor architecture of the fig1 device and has only an indirect effect on the virtualization capability . when the arbiter 102 operates to allow an ingress ethernet packet through , the protocol header , the guest_idx steering index and an indication of whether the mac address is unicast , multicast or broadcast attached to the header by the mac device , are provided to the protocol processing block 107 . the protocol processing block 107 includes a lookup block 108 that locates the state for an offloaded protocol such as tcp and that is additionally used to filter packets ( e . g ., obtain filtering rules ) that , for example , do not have a destination ip address that is consistent with the guest_idx steering index . a packet is identified by the header or headers that the packet contains . as an example , the headers for ethernet packets contain at least a protocol stack layer - 2 ethernet packet , and when the ethernet packet encapsulates an ip packet , a packet will also contain a layer - 3 ip header , and when the ip header encapsulates a layer - 4 tcp ( or udp ) protocol , it will also contain a tcp ( udp ) header . for a tcp packet , a 4 - tuple including a source and destination ip address and a source and destination port numbers is said to uniquely identify a point - to - point connection that uses the protocol . for offloaded connections , the lookup minimally considers the 4 - tuple information and the ethernet address lookup index guest_idx steering index corresponding to the destination ethernet mac address . in addition , the lookup may consider information about the virtual local area network ( vlan ) to which the packet belongs , when vlan &# 39 ; s are being used , and perhaps the nic port on which the packet arrived . in some examples , the lookup block 108 operates to match the protocol header to an internal identification (“ tid ,” used by the interface device and the host ) corresponding to a particular protocol or filtering rule control block ( cb ). in the fig3 example the lookup database is implemented with a tcam memory , which allows looking up the location of a cb in pipelined fashion , with one tid result being returned from the tcam every clock cycle after a pipeline startup delay . in place of the tcam , other structures ( such as hashing or a search tree ) may be employed for lookup . the lookup block 108 then provides the tid , received from the tcam 110 , to connection manager circuitry 112 that manages the cb connection state and attributes . in the fig3 example , the connection state and attributes are in a control block ( cb ) 114 . the connection manager 112 operates in concert with the payload command manager 116 to generate and provide payload commands to a payload manager block 118 . in particular , for offloaded connections , the connection manager 112 provides the tid to the cb 114 , and the cb 114 provides the current connection state and attributes for the connection ( i . e ., the connection to which the tid corresponds ) to the connection manager 112 . based on the current connection state and attributes provided from the cb 114 , the connection manager 112 determines that the connection state corresponds to an offloaded connection , how to appropriately modify the connection state and provides , to the payload command manager 116 , an indication of the modification to the connection state . based on the indication of the modification , the payload command manager 116 issues one or more appropriate payload commands to the payload manager block 118 to cause payload data to be forwarded to the host ( via the form packet block 120 ) or to create rx modulation events to schedule delivery of data to the host . the packet formed by the form packet block 120 contains the guest_idx steering index . the cb also contains the guest_idx value to use when sending packets to the host . for filtering rules , the cb includes an indication of whether a packet is to be forwarded to the host or is to be dropped . in the context of the virtualization functionality discussed above , a dropped packet might , for example , correspond to a packet with a matching mac address but with an ip address that is not consistent with the particular mac address . for offloaded connections , the connection manager 112 writes the modified connection state and attributes back into the cb 114 . the read , modify and write of the connection state and attributes is done in an atomic operation . here , “ atomic ” refers to the property that a read of the cb always returns the most recent state of the particular cb , even though the pipeline might be processing multiple messages simultaneously , that are associated with the same cb . the connection manager 112 provides an appropriate packet header for data transmission to a form packet block 120 . meanwhile , the payload manager block 118 provides the corresponding payload to the form packet block 120 ( as discussed above , based on payload commands from the payload command manager 116 ). the form packet block 120 combines the packet header and corresponding payload into a packet for transmission to the host computer . in the fig3 example , packet data is transmitted to the host in a control protocol language ( cpl ) message encapsulated manner so the form packet block 120 issues cpl messages for transmission to the host computer by the dma ( direct memory access ) block 130 . the cpl message includes an index derived from the guest_idx steering index into a structure that points to the appropriate scatter - list queue and response - queue . for a direct data placement ( ddp ) message , the destination memory address is found and placed in an appropriate cpl ddp message . the response message uses the response - queue index to place a ddp buffer completion message , if applicable , in the appropriate completion queue . the cpl message arrives at the dma engine 130 that looks up the free - list to use based on the provided index , and the response queue to use based on the provided index , and dma writes the cpl message to the selected free - list , or in the ddp case writes the data to that particular physical memory address , and if applicable , writes a buffer completion message to the response queue when the dma write of the payload is done . turning now to fig4 , an example is shown schematically of a design for an 8 - way virtual nic 500 , with two 10 gbps ethernet ports 510 a and 510 b . this example for the sake of illustration is in the context of multiple guest os &# 39 ; s executing on a host system . eight instances of guest os &# 39 ; s 520 a - 520 h are running in a host computer on top of a vos 530 . the nic implements “ stateful ” functionality such as for iscsi , rdma , and / or tcp offload engine toe functionality , in additional to the stateless offload functionality such as large send and checksum offload . each of the eight instances of guest - os &# 39 ; s 520 a - 520 h in the fig4 example has its own mac address ( ethernet / layer - 2 address ). further , each of the instances of guest - os &# 39 ; s has one or more of its own local internet protocol addresses ( lip ). the different guest - os &# 39 ; s would not , in general , have the same lip address except for instances of guest - os &# 39 ; s on different vlans since , otherwise , this would result in error conditions ( e . g ., would imply responses by two stacks within different instances of guest - os &# 39 ; s to arp requests , etc .). each guest os instance may independently configure the nic with rules for filtering multicast mac addresses and multicast ip addresses . an example of processing steps to utilize the fig4 nic circuitry 500 is now described with reference to fig5 . at step 502 , the destination mac address ( da ) of an ingress level 2 ethernet packet is extracted from the packet . at step 504 , the da is matched with the eight filtering database perfect match local address entries 540 a or 540 b ( fig4 ) depending on the interface on which the message arrives , and a 3 - bit source address index is derived ( int0 - idx for interface - 0 , or int1 - idx for interface - 1 ) or the packet , if non - matching , is dropped . at step 506 , the local address index is mapped to the guest_idx ( steering index ), which indicates the guest os instance to which the da is mapped . at step 508 , the steering index is included as part of the tuple used to look up the tid ( as described with reference to fig3 ). before continuing on with describing fig5 , it is noted that , in general , the connection state block for offloaded packets includes information useable to steer , to the correct free - list and response queues , packets belonging to each particular connection . for example , the state block may contain the cpu number on which the corresponding guest os instance is running , and the cpu number can then be mapped to the queues using a programmable mapping table . in some examples , for non - offloaded packets , the guest_idx is used , along with possibly other fields of the packet , to steer each packet to the correct free - list and response queue . this can be achieved by computing an index into a mapping table , the index based on the guest_idx and a hash of a combination of , for example , the ( lip , fip , lp , fp ) fields when available in the packet . the computed index can then be used to look up an intermediate index , which , in turn can be used to lookup a free - list index and a response - queue index in a programmable mapping table . a result is that traffic “ belonging ” to one guest os instance can be distributed to different cpus and queues for load balancing . for example , for the eight guest - os instance example , one entry for each map 540 a and 540 b could be configured to map to the same 5th tuple value such that each guest - os instance is allocated one local mac address in the filtering database on each interface . the 5th - tuple returned for each interface could then map to the same free - list index , and the same response queue index . the ingress messages destined for a particular guest - os would , in this manner , map to the same free - list and response queue , and the ingress messages destined for different instances of guest - os &# 39 ; s would map to different free - lists and response queues . another resulting observation is that different instances of guest - os &# 39 ; s can share the same local source mac address and the steering of the traffic to the different instances of guest - os &# 39 ; s be based on other information , such as all or part of the 4 - tuple . in summary , 5 - tuple virtualization has an advantage of allowing the nic to be run with mac address matching that enables layer - 2 demultiplexing , and also enabling the switching of ingress unicast packets on the nic ( other than broadcast and multicast packets , which would typically require additional processing on the nic or in the host ). in addition , the use of vlan tags ( to partition a lan into many virtual lan &# 39 ; s ) is naturally supported by this scheme , by including the vlan tag as part of a 6 - tuple that is used to determine the index . we now return to fig5 . as discussed above with reference to steps 502 , 504 , 506 and 508 of fig5 , initially , ingress level - 2 packets are processed to determine a tid ( identifying a state block corresponding to upper layer information encapsulated in the layer - 2 packet ) and a steering index . the flow chart in fig5 shows the processing of ingress packets from the time they enter the intelligent network interface circuitry until a cpl message is sent to a particular free - list / response queue ( or rq / cq for iwarp , a type of dma interface , i . e ., request queue and completion queue ). at step 510 , it is determined if the packet is an offloaded connect request packet , such as a tcp syn packet . if so , then at step 512 it is determined if the 6 - tuple ( step 508 ) is already in use . if so , then a rst error message may be sent back to the peer that sent the connection request message . if the 6 - tuple is not already in use , then a tcb entry is initialized at step 514 . in addition , at step 516 , the steering index is used to look up a free - list and response queue for use with the connection . at step 518 , a cpl command is provided to the host indicating that the connection was setup and indicating the parameters of the connection . if , at step 510 , it is determined that there was no hit in the tcam for offload processing ( step 508 ) for the 6 - tuple , then the layer - 2 packet is a tunnel packet , which is to be provided to the host without substantial protocol processing by the network interface circuitry . in this case , at step 520 , the steering index is used to look up a scatter - list and response - queue for the connection , and a control protocol message is sent to the host at step 522 indicating receipt of the “ tunnel ” ( non - offloaded ) packet . if it is determined that there was a hit in the tcam for offload processing for the 6 - tuple , then at step 524 it is confirmed that the steering index is contained in the tcb entry indirectly indicated by the 6 - tuple . if the steering index is not contained in the tcb entry , then the packet is dropped . otherwise , the packet is processed according to the offloaded protocol ( tcp , in the illustrated case ) and the data is communicated as appropriate to the host computer , according to the principles discussed above . with regard to egress packets , as discussed above , egress virtualization is achieved by using different command queues and response queues for the different guest - os &# 39 ; s , and gather - lists use physical memory locations that can not be accessed by ( that are not mapped for ) the other guest - os &# 39 ; s . internally to the nic , traffic belonging to different guest functions or guest os &# 39 ; s may be discriminated and treated differently according to traffic management . traffic management in both the receive and transmit direct is described in several pending patent applications , each of which is incorporated herein by reference in its entirety : u . s . patent application ser . no . 11 / 217 , 661 , filed aug . 31 , 2005 and entitled “ protocol offload transmit traffic management ”; u . s . patent application ser . no . 11 / 282 , 933 , filed nov . 18 , 2005 and entitled “ a method for udp transmit protocol offload processing with traffic management ”; and u . s . patent application ser . no . 11 / 313 , 003 , filed dec . 19 , 2005 and entitled “ a method for traffic scheduling in intelligent network interface circuitry .”