the present invention defines techniques for improving the efficiency of data transfer in systems designed according to a virtual network architecture and / or systems which support multiple operating system images in distinct logical partitions . note that while preferred embodiments are described herein in terms of a particular mainframe computer ( i . e . the z900 ) which supports a particular operating system , and the hipersockets feature of this computer , this is for purposes of illustration and not of limitation . furthermore , references herein to use of the present invention for processing ip packets is for purposes of illustration and for conveying details of implementing the present invention . the disclosed techniques may be used advantageously in other computing environments , including with other computers , other operating systems , and other networking protocols , without deviating from the scope of the present invention . in a first preferred embodiment , a host which sends packets onto a virtual lan manages a set of packing buffers , and separates outbound packets into appropriate ones of these packing buffers based on the next - hop ip address for each packet . note that this host , which is referred to herein as a “ sending host ”, is not necessarily the host which originally generates the packets . ( the sending host determines the next - hop ip address for a particular packet by using the destination ip address from the packet &# 39 ; s ip header to access a routing table for a route corresponding to that destination , using techniques which are known in the art and which do not form part of the present invention .) by separating the outbound packets in this manner , a particular packing buffer accumulates packets destined for a single next - hop address . when an appropriate threshold ( which may depend on the current workload of the system ) is reached to indicate that buffered packets should be transmitted ( such as expiration of a timer , reaching a counter of buffered packets , filling a packing buffer , etc . ), the host sends one or more of the packing buffers to the device driver , using a single i / o operation , for routing the buffer ( s ) onto the virtual lan . preferably , a “ siga ” ( signal adapter ) instruction is used for this sending of packing buffers , where the data sent on this instruction equates to a single “ transmission unit or frame ” for which the siga command is designed . the device driver can then quickly transmit the entire unit ( comprising one or more packets ) to the target host , and only needs to look at the next - hop ip address of the first packet in each packing buffer in order to determine where to send the entire set of packets in that packing buffer or frame . this approach makes it transparent to the device driver how many packets the host is sending , and shields the device driver from having to inspect each packet header in order to send the buffered packets , thereby greatly improving the efficiency of the packet forwarding process . ( the signal adapter instruction is defined in commonly - assigned u . s . pat . no . 6 , 345 , 325 , ser . no . 09 / 252 , 728 , filed feb . 19 , 1999 , which is entitled “ a method and apparatus for ensuring accurate and timely processing of data using a queued direct input - output device ”.) because the sending host builds ip headers on each packet , the eventual receiving ( target ) host can parse through the header of each received packet while completing its processing of each packet in the inbound buffer , with no loss of information . in a second preferred embodiment , the above - described technique may optionally be further optimized by basing the packing algorithm not only on the next - hop ip address , but on the final destination ip address as well . preferably , each packing buffer for outbound data is logically subdivided by the sending host on particular boundaries when using this optimization , and packets are accumulated within these logical subdivisions for particular final destinations . a boundary such as a 4k page ( i . e . 4 , 096 bytes ) may be used , where the 4k size ( or another appropriate size ) is selected to correspond to a frame size of the computing system . in this manner , the packing buffer still represents data to be sent to a particular next - hop ip address , while each 4k page within that buffer contains packets for the same final destination ip address . this enables each receiving ( intermediate ) host to quickly scan through an inbound buffer and separate its own traffic from traffic that must be routed to a different target host , without having to individually inspect the header of each packet in the buffer . instead , the receiving host checks the destination address of the first packet in each 4k page or frame . if the ip header contains this host &# 39 ; s ip address , then the host accepts all of the packets in this frame for further processing ; otherwise , the entire frame is forwarded to the next hop . first and second preferred embodiments will now be described in more detail with reference to the logic depicted in the flowcharts of fig2 and 3 , making reference to the examples in fig4 a - 4h . the logic in fig2 and 3 assumes that a sending host has data packets ready for transmission , and iterates through these packets sequentially . referring to fig2 , in a first preferred embodiment , the packing algorithm begins at block 200 by initializing a variable “ s ” to zero . variable s counts how many elements in an array referred to herein as “ array ” are valid . block 205 tests to see if more packets are ready to be packed for transmission . if not , then the packing buffer may be transmitted at block 210 , after which the processing of fig2 is ( at least temporarily ) complete . otherwise , the packing operation continues at block 215 where a variable “ k ” is initialized to one . variable k is used to index through array . block 220 tests to see if variable k has a greater value than variable s . if so , then there are no more packing buffers to be checked in the current iteration , indicating that no existing buffer is available for packing the current packet . the processing for this situation uses blocks 250 - 265 , as will now be described . reference is now made to the five example packet fragments in fig4 a , which are used to illustrate operation of the packing algorithm in fig2 . ( as will be obvious , this sample data is provided for purposes of illustration , and is not meant to reflect actual addressing conventions or actual packet contents .) on a first iteration through this logic , packet 405 is the current packet being processed ; variable s = 0 ; and variable k = 1 . therefore , control transfers from block 220 to block 250 ( because no packing buffer is available for packing packet 405 ). at block 250 , a new packing buffer is obtained . variable s is incremented ( block 255 ), indicating that an additional element of array is now valid , and variable k now indexes to this new array element . in the example of fig4 a , s = 1 and k = 1 at this point , and buffer 420 of fig4 b has been obtained . block 260 then initializes the next - hop field of array [ k ] to the next - hop address from the current packet . fig4 b shows that the next - hop value 431 of array [ 1 ] 430 is set to “ 123 ”, which is the value shown in column 401 of fig4 a for packet 405 . block 265 initializes the packing area field of array [ k ] to the point to the start of the new outbound packing buffer . fig4 b shows that array [ 1 ]&# 39 ; s packing area field 432 points to outbound buffer 420 . control then transfers to block 235 of fig2 . in block 235 , a variable “ current_packing_area ” is set using the current packing area field value from the k - th element of array . in the example , current_packing_area thus points to outbound packing buffer 420 , in accordance with field 432 of array [ 1 ]. block 240 copies the current packet into the packing buffer at the location pointed to by current_packing_area . this is shown by the new values in buffer 420 of fig4 c , where the current packet 405 in the example has the content “ 123abc ”. block 245 then sets the k - th array element &# 39 ; s packing area field to point to the new location computed as ( current_packing_area + the length of the current packet ). fig4 c therefore shows array 430 having its packing area field 432 changed to point to the next empty location in packing buffer 420 . control then returns to block 205 to determine whether there are more packets to be packed . in the example , the second iteration through the logic of fig2 uses packet 406 as the current packet , and has s = 1 . at block 215 , k is reset to 1 . the “ no ” branch will therefore be taken from the test in block 220 . when the test in block 220 has a negative result , this indicates that there are still more outbound packing buffers to inspect , and control transfers to block 230 . block 230 checks to see if the next - hop address of the current packet being processed matches a saved next - hop address in the k - th element of array . in the example , this test has a negative result because array [ 1 ] contains the value “ 123 ” in its next - hop field while the current packet has the next - hop value “ 456 ”. control therefore passes to block 225 , which increments k and returns to the test in block 220 . at this point in the example , the test in block 220 has a positive result , indicating that there are no more packing buffers which might contain packets destined for the next - hop address of “ 456 ”. therefore , the logic in blocks 250 - 265 will be executed again . a second packing buffer 422 is obtained during this processing , as shown in fig4 d . variable s is incremented to 2 . k is already set to 2 , from the processing of block 225 . array [ 2 ] has its next - hop address 433 set to “ 456 ” and its packing area field points to the start of packing buffer 422 . upon transferring to the processing of blocks 235 - 245 ( which have been described in detail above with reference to the processing of the first packet 405 ), the current_packing_area is set to also point to the start of packing buffer 422 ; the current packet is copied into this packing buffer ; and the value of the packing area field in array [ 2 ] is changed to point to the next empty location within packing buffer 422 , with the result as shown in fig4 e . after completing the processing of the second packet 406 , control again returns to block 205 to begin processing packet 407 . s is now 2 , and k is again reset to 1 at block 215 . k is not greater than s , and control therefore reaches block 230 , which compares the next - hop value “ 123 ” from packet 407 to the next - hop value in array [ 1 ]. because these next - hop values match , processing continues at block 235 which uses the packing area field 432 from array [ 1 ] to set the value of current_packing_area . the contents of packet 407 are then copied into packing buffer 420 starting at the next available position ( block 240 ), and the pointer in packing area field in array [ 2 ] is moved beyond this new content ( block 245 ), with the result as shown in fig4 f . control then returns again to block 205 . the processing of this logic for the example packets 408 and 409 will not be described in detail , as it will be obvious to the reader . the results are shown in fig4 g , assuming that no more packets are available or otherwise ready for transmission , the test in block 205 will have a negative result . the packing buffers 420 , 422 , 424 are then sent to the device driver for a memory - to - memory transmission at block 210 . upon re - entering the logic of fig2 to process additional outbound packets , all variables are re - initialized and all packing buffers are obtained anew . turning now to fig3 , logic which may be used to implement the above - described second preferred embodiment is illustrated . this logic in blocks 300 - 370 of fig3 corresponds generally to blocks 200 - 265 of fig2 , and differs from that of fig2 only in the addition of blocks 336 , 337 , 338 , and 370 . after determining in block 330 that a packing buffer having a next - hop address equal to that of the current packet is available , and setting current_packing_area to point to the next empty position in that buffer at block 335 , additional processing is performed in block 336 to determine whether the final destination of the current packet matches the final destination in the 4k frame to which current_packing_area now points . this test uses an additional field in each array element , shown in the array 440 of fig4 h as 443 ( which assumes that packet 401 of fig4 a was directed to a final destination having the address “ 321 ”). this additional array field remembers the destination address for the 4k frame to which the packing area field of each array element currently points . this destination address field of each array element is originally set during the processing of block 370 , after a packing buffer was newly obtained for a next - hop address for which no existing packing buffer was found . if the destination address matches during the test of block 336 , then control transfers to block 340 where the current packet is inserted into the packing buffer at the next available location within the 4k frame ( as has been described above with reference to inserting the current packet into the next available location of the overall packing buffer at block 240 of fig2 ). otherwise , processing continues at block 337 , which advances the current_packing_area value to the next 4k frame within the packing buffer for the appropriate next - hop address , and block 338 then updates the saved destination address field ( see 443 of fig4 h ) of array [ k ] to remember the current packet &# 39 ; s destination address . it will be obvious to one of skill in the art that the logic depicted in fig2 and 3 omits certain details which are not relevant to the novel concepts of the present invention , such as ensuring that array contains enough space to enable adding a new element for some value of k , ensuring that the packing buffers have not overflowed ( and obtaining a new packing buffer if an overflow does occur ), and so forth . the manner in which the logic can be augmented with these details , which use techniques that are well known in the art , will be readily apparent . when the packing buffers created according to the above teachings are transmitted , the receiving ( target and intermediate ) hosts are preferably adapted to knowing that the efficient packing and transmission technique of the present invention is in use , thereby enabling those hosts to avoid parsing each individual packet header for packet routing purposes . the receiving hosts may obtain this knowledge in various manners . preferably , all sending hosts on the virtual lan implement at least the first preferred embodiment described above . in that case , it is only necessary for receiving hosts to know whether a particular sending host uses the enhanced technique of the second preferred embodiment . one way in which this might be known is for each sending host to transmit a special flag within the packet headers to indicate this information . or , a system - wide convention might be adopted , requiring that either all sending hosts implement the first preferred embodiment or the second preferred embodiment , but not allowing a mix . as another example , a message exchange might be used to convey this information , such as by transmitting a special protocol message to inform a recipient that the second preferred embodiment is in use ( or whether or not it is in use ) at a particular sending host . note that there are no requirements placed on receiving hosts for conveying information as to which embodiment it supports : the receiving host simply inspects the first packet header of the received buffer , or the first packet header of each 4k frame within the received buffer , depending on which preferred embodiment it supports . as has been demonstrated , the present invention provides advantageous techniques for improving efficiency of data transfer within virtual networks . use of either preferred embodiment may result in significantly faster packet delivery . as will be appreciated by one of skill in the art , embodiments of the present invention may be provided as methods , systems , and / or computer program products . accordingly , the present invention may take the form of an entirely hardware embodiment , an entirely software embodiment , or an embodiment combining software and hardware aspects . furthermore , the present invention may take the form of a computer program product which is embodied on one or more computer - usable storage media ( including , but not limited to , disk storage , cd - rom , optical storage , and so forth ) having computer - usable program code embodied therein . the present invention has been described with reference to flowchart illustrations and / or block diagrams of methods , apparatus ( systems ), and computer program products according to embodiments of the invention . it will be understood that each block of the flowchart illustrations and / or block diagrams , and combinations of blocks in the flowchart illustrations and / or block diagrams , can be implemented by computer program instructions . these computer program instructions may be provided to a processor of a general purpose computer , special purpose computer , embedded processor or other programmable data processing apparatus to produce a machine , such that the instructions , which execute via the processor of the computer or other programmable data processing apparatus , create means for implementing the functions specified in the flowchart and / or block diagram block or blocks . these computer program instructions may also be stored in a computer - readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner , such that the instructions stored in the computer - readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart and / or block diagram block or blocks . the computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart and / or block diagram block or blocks . while preferred embodiments of the present invention have been described , additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts . in particular , while the preferred embodiments have been described with reference to ip and tcp / ip , this is for purposes of illustration and not of limitation . therefore , it is intended that the appended claims shall be construed to include the described preferred embodiments and all such variations and modifications as fall within the spirit and scope of the invention .