WO2024172985A1

WO2024172985A1 - High speed inter-processor file exchange mechanism

Info

Publication number: WO2024172985A1
Application number: PCT/US2024/012050
Authority: WO
Inventors: Saran Krishnaswamy; Andrei Tudorancea; Jesus A GUTIERREZ GOMEZ; Carsten J PEDERSEN; Bhanutheja Nagabhushana REDDY KASINAYAKANAHALLY; Nandhini MANOHARAN
Original assignee: Apple Inc.
Priority date: 2023-02-15
Filing date: 2024-01-18
Publication date: 2024-08-22

Abstract

Disclosed are techniques for transferring large files between two processors such as an application processor (AP) and a baseband chip (BB) using a file exchange mechanism that dynamically allocates bidirectional memory-mapped regions for buffering payloads based on the size of the file transfer between the AP and BB. The file exchange mechanism provides a scalable transport channel for the AP to read control/configuration information from, or write control/configuration information to, the BB. The AP and BB may exchange payloads of files containing control/configuration information through the dynamically allocated memory-mapped region while using a separate communication channel for coordinating and synchronizing the payload exchange. The AP may allocate the memory-mapped region based on the size of the file payload to be transferred. A transfer session may include one or more files logically grouped for a particular use scenario and the transfer of the files are treated as an undivided atomic operation.

Description

HIGH SPEED INTER-PROCESSOR FILE EXCHANGE MECHANISM

FIELD

[0001] This disclosure relates to mechanisms and techniques for transferring fdes between multiple processing entities. In particular, disclosed are frameworks and methods for transferring or exchanging fdes such as control and/or configuration information between an application processor and a baseband component of a communication device. Other aspects are also described.

BACKGROUND

[0002] Portable consumer electronics devices such as smartphones, tablet computers, smart watches, and other communication devices have an application processor (AP) for handling user application functions and a baseband chip (BB) for handling lower-level communication functions. The AP and clients connected to the AP may communicate with the BB and its clients using hardware mechanisms such as peripheral component interconnect express (PCIe) transport or general-purpose input/output ports (GPIO). PCIe provides high speed transport between the AP and BB using different logical channels for various data types or use cases. For example, control-plane channels are used to exchange control and/or configuration (hereinafter control/configuration) information related to booting, configuring, managing, and debugging the BB. Data-plane channels are used to exchange information related to user-data packets such as data related to browsing, voice over IP (VoIP) calls, application notifications, etc. Payloads sent over the control-plane channels are generally smaller than those for the data-plane channels and are conventionally segmented into small chunks such as 3 KB messages for transfer. However, scalability of transfer using control-plane channels becomes an issue as the size of control/configuration information payload increases. Transferring large payloads in segmented messages may throttle the throughput of the control-plane channels, introduce long latency and roundtrip delay, and degrade the performance of the BB and clients connected to the AP and the BB. It is desirable to provide a mechanism to transfer large files efficiently and reliability between the AP and BB.

SUMMARY

[0003] Disclosed are techniques for transferring large files between two processors such as an AP and a BB using a file exchange mechanism that dynamically allocates bi-directional memory-mapped regions for buffering payloads based on the size of the file transfer between the AP and BB. The file exchange mechanism provides a scalable transport channel for the AP to read control/configuration information from, or write control/configuration information to, the BB. The AP and BB may exchange payloads of files containing control/configuration information through the dynamically allocated memory-mapped region while using a separate communication channel for coordinating and synchronizing the file pay load exchange. In one application, the AP may use the file exchange mechanism to transfer large files of control/configuration information related to booting, managing, and debugging of the BB. For example, high-level clients of the AP of a cellular device may use the file exchange mechanism to transfer large files to or from the BB such as when performing boot-up image push, control message exchange, trace-log collection, non-volatile memory (NVM) synchronization, preferred roaming indicator (PRI) push, subscriber identification module (SIM) transfer, machine learning training, etc.

[0004] A client of the AP may create a transfer session containing one or more files and may initiate a transfer session request to transfer the files within the session. The files in the session may include write files to the BB and/or read files from the BB. A session may be considered a logical grouping of files for a particular use scenario. The AP acting as a file exchange server may serialize requests from multiple clients in a queue and may run a scheduling algorithm to select transfer sessions from the queue. In one aspect, only one transfer session may be active at a time. The file exchange server may treat the transfer of files in the session as an undivided atomic operation, transferring one file at a time until all files of the session are transferred or error conditions are encountered before selecting the next session from the queue. The session may not be considered complete or successful until all the files have been transferred.

[0005] For each file in an active session, the AP may dynamically allocate a memory-mapped region as a transport channel based on the size of the file for exchanging the payload of the file with the BB. The AP may use a separate communication channel for coordinating the file exchange with the BB such as to initiate transfer requests, communicate file metadata information, synchronize operations, etc. For example, the AP and BB may communicate the size of each file transfer using the communication channel. The communication channel may be considered an out-of-band message channel (or simply ‘message channel’). In one aspect, when a session includes a file read from the BB, such as an operation by a NVM synchronization client of the AP to read the NVM image of the BB, the AP file exchange server may request the size of the file from the BB through the communication channel. In one aspect, when a session includes a file write to the BB, such as an operation by the NVM synchronization client of the AP to push the boot-up image to the BB, the AP file exchange server may communicate to the BB the size of the file through the communication channel.

[0006] The file exchange server of the AP may be the controlling entity that initiates file transfer sessions as requested by the clients of the AP. A BB processor acting as a file exchange server for the BB may coordinate with the clients of the BB to respond to the file transfer sessions. In one aspect, the file exchange server of the AP and the file exchange server of the BB may communicate with their respective clients about the status of the file transfer via callback channels registered by the clients. In one aspect, the file exchange server of the AP may handle all error scenarios such as timeouts, transfer/checksum errors, BB-crashes, etc., and determine the corrective actions. Advantageously, by using a dynamically allocated memory region to transfer unsegmented payloads coordinated through an out-of-band message channel, the AP and BB may exchange large files containing control/configuration information in a scalable, robust, and fast manner to improve the operations of clients connected to the AP and BB.

[0007] A method for sequencing file transfers of a transfer session between an AP and a BB using dynamically allocated memory-mapped regions is disclosed. The method includes examining by the AP its session queue for one or more sessions requests from one or more AP clients. A session request from an AP client may contain requests to exchange one or more files with the BB. If the session queue has at least one session requests, the AP selects a session request and selects a first file contained within the selected session request. The AP obtains file information such as the file size of the selected file from the requesting AP client or the BB. In one embodiment, if the selected file is to be read from the BB, the AP may request the file information of the to-be-read file from the BB. In one embodiment, if the selected file is to be written to the BB, the AP may request the file information of the to-be-written file from the requesting AP client. The AP allocates a memory-mapped region based on the file information, such as allocating the correct size of the memory-mapped region to contain the file. The AP initiates the transfer of the selected file with the BB through the memory-mapped region. At the completion of the file transfer, the AP de-allocates the memory-mapped region and selects the next file contained within the selected session request. The AP successively allocates and de-allocates memorymapped regions based on the file information of the selected files for file transfer until all files contained within the selected session request have been transferred. The AP repeats the process with the next session request in the session queue until all session requests are handled.

[0008] A method for exchanging a file between two processors using a dynamically allocated memory-mapped region as a transport channel coordinated by an out-of-band message channel is disclosed. The method includes a first processor receiving a request from a client of the first processor to exchange a file with a second processor. The first processor exchanges metadata of the file with the second processor through a message channel. In one embodiment, the metadata may include information such as the size of the payload of the file. The first processor allocates a memory-mapped region as a transport channel based on the metadata of the file, such as allocating the memory-mapped region to be the payload size of the file. The first processor coordinates with the second processor through the message channel a transfer of the file. The first processor transfers to the second processor, or transfers from the second processor, the file through the transport channel provided by the memorymapped region. In one embodiment, the file transferred includes undivided content of the file. In one embodiment, the file transfer operation may include the first processor reading the file from the second processor or the first processor writing the file to the second processor through the memory-mapped region. Upon completion of the file exchange, the first processor de-allocates the memory-mapped region.

[0009] The above summary does not include an exhaustive list of all aspects of the present disclosure. It is contemplated that the disclosure includes all systems and methods that can be practiced from all suitable combinations of the various aspects summarized above, as well as those disclosed in the Detailed Description below and particularly pointed out in the claims filed with the application.

Such combinations have particular advantages not specifically recited in the above summary.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Several aspects of the disclosure here are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to "an" or “one” aspect in this disclosure are not necessarily to the same aspect, and they mean at least one. Also, in the interest of conciseness and reducing the total number of figures, a given figure may be used to illustrate the features of more than one aspect of the disclosure, and not all elements in the figure may be required for a given aspect.

[0011] FIG. 1 depicts a high level processing model of a file exchange mechanism to transfer files between an application processor (AP) and a baseband chip (BB) through a memory-mapped region, according to one aspect of the disclosure.

[0012] FIG. 2 depicts a more detailed processing model of a file exchange mechanism mediated by an AP file exchange server and a BB file exchange server to transfer files between clients of the AP and the BB through a memory-mapped region coordinated by an out-of-band message channel, according to one aspect of the disclosure.

[0013] FIG. 3 is a flow diagram of a method for an AP to sequence file transfers of a transfer session between the AP and a BB using dynamically allocated memory-mapped regions, according to one aspect of the disclosure.

[0014] FIG. 4 is a control flow diagram of AP clients reading files of a transfer session from BB clients mediated by an AP file exchange server and a BB file exchange server through a memorymapped region that is allocated based on the size of files read from the BB clients, according to one aspect of the disclosure.

[0015] FIG. 5 is a control flow diagram of AP clients writing files of a transfer session to BB clients mediated by an AP file exchange server and a BB file exchange server through a memorymapped region that is allocated based on the size of files written to the BB clients, according to one aspect of the disclosure.

[0016] FIG. 6 is a control flow diagram of AP clients requesting file transfer sessions with BB clients as scheduled by an AP file exchange server using dynamically allocated memory-mapped regions as a transport channel to a BB file exchange server, according to one aspect of the disclosure. [0017] FIG. 7 is a control flow diagram of an AP file exchange server dynamically allocating memory-mapped regions as a transport channel to read files requested by AP clients from BB clients through a BB file exchange server based on the read file size, according to one aspect of the disclosure. [0018] FIG. 8 is a control flow diagram of an AP file exchange server dynamically allocating memory-mapped regions as a transport channel to write files requested by AP clients to BB clients through a BB file exchange server based on the write file size, according to one aspect of the disclosure. [0019] FIG. 9 is a flow diagram of a method for a first processor to exchange a file with a second processor using a dynamically allocated memory-mapped region as a transport channel coordinated by a message channel, according to one aspect of the disclosure.

DETAILED DESCRIPTION

[0020] Electronic devices may use control-plane channels to transfer signaling messages, control/configuration information, etc., between processing units executing different layers of a software protocol stack. For example, in a cellular device an application processor (AP) connected to higher- layer clients may use PCIe transport to communicate information related to booting, managing, and debugging of a baseband (BB) communication chip. As cellular devices grow in complexity and capabilities, and as the size of signaling information and control/configuration messages exchanged between the AP and BB increases, it is important to provide a high-speed file exchange mechanism to transfer large files between the AP and BB in a scalable, robust, and fast manner.

[0021] Disclosed are techniques and methods of a high-speed inter-processor framework that uses dynamically allocated, dedicated, and bi-directional memory-mapped-based transport channel to exchange payload of files between the AP and BB. The AP, acting as the main controlling entity, may allocate a memory-mapped region based on the size of the file payload to buffer a file read by the AP from the BB or a file written from the AP to the BB. In a read-from-BB operation, the BB may store the payload of the requested file in the memory-mapped region for retrieval by the AP. In a write-to-BB operation, the AP may store the payload of the write file in the memory-mapped region for retrieval by the BB. A transfer session may include one or more files logically grouped for a particular use scenario. Transfer of files in a transfer session are treated as an undivided atomic operation and only one transfer session may be active at a time. The AP may execute a scheduling algorithm to sequentially select transfer sessions requested by one or more clients of the AP and stored in a request queue.

[0022] The framework uses a separate message channel for metadata to coordinate and synchronize the use of the memory-mapped-based transport channel by the BB under the control of the AP. For example, the AP may use the message channel to initiate transfer requests to the BB, obtain the payload size of files to be read from the BB for allocating memory-mapped regions, provide the payload size of a file to be written to the BB to prepare the BB to receive the file, receive status of file transfer or error conditions from the BB, etc. The AP may handle all error scenarios such as timeouts, transfer/checksum errors, BB-crashes, etc., and take the corrective actions. High-level clients of the AP may use the framework to exchange large fded with clients of the BB for operations such as boot-up image push, control message exchange, trace-log collection, non-volatile memory (NVM) synchronization, preferred roaming indicator (PRI) push, subscriber identification module (SIM) transfer, machine learning training, etc.

[0023] In the following description, numerous specific details are set forth. However, it is understood that aspects of the disclosure here may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description.

[0024] The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of the disclosure. Spatially relative terms, such as "beneath", "below", "lower", "above", "upper", and the like may be used herein for ease of description to describe one element's or feature's relationship to another element(s) or feature(s) as illustrated in the figures. It will be understood that the spatially relative terms are intended to encompass different orientations of the device in use or operation in addition to the orientation depicted in the figures. For example, if the device in the figures is turned over, elements described as "below" or "beneath" other elements or features would then be oriented "above" the other elements or features. Thus, the exemplary term "below" can encompass both an orientation of above and below. The device may be otherwise oriented (e.g., rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein interpreted accordingly.

[0025] As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms "comprises" and "comprising" specify the presence of stated features, steps, operations, elements, or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, or groups thereof.

[0026] The terms “or” and “and/or” as used herein are to be interpreted as inclusive or meaning any one or any combination. Therefore, “A, B or C” or “A, B and/or C” mean any of the following: A; B; C; A and B; A and C; B and C; A, B and C.” An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.

[0027] FIG. 1 depicts a high level processing model of a file exchange mechanism to transfer files between an AP 120 and BB 220 through a memory-mapped region, according to one aspect of the disclosure.

[0028] AP 120 may provide service to multiple AP clients 131, 132, and 133 to transfer controlplane data to or from BB clients 231, 232, 233 serviced by BB 220. The control-plane data may include signaling messages and control/configuration information related to booting, managing, and debugging, etc., of BB 220. For example, AP client 131 may perform BB NVM synchronization when starting or shutting down BB 220 by transferring NVM files to BB client 231. AP clients 131, 132, and 133 may execute a transfer at any point during system execution by creating a transfer session object. A transfer session object (also known as transfer session or simply session) may include one or more files logically grouped by function.

[0029] AP file exchange protocol (FEP) server 140 implementing the high-speed inter-processor file transfer mechanism may serialize the sessions requested by AP clients 131, 132, and 133 in session queue 142. When a session from an AP client is queued, the AP client may provide file IDs of the files to be transferred during that session. In one embodiment, file IDs are common across AP 120 and BB 220 and are statically agreed between AP 120 and BB 220 at design time.

[0030] A scheduler 144 of AP FEP server 140 may run session state machine 146 or execute a scheduling algorithm to select a session from session queue 142. AP FEP server 140 may successively transfer files in the selected session to or from clients of BB 220 as designated by the session or the files. Only one session may be active at a time. AP FEP server 140 may get the size of a file to transfer from the AP client that requested the active session or the designated BB client. For example, when an AP client requests a file write to a BB client, AP FEP server 140 may obtain the size of the file from the AP client. When an AP client requests a file read from a BB client, AP FEP server 140 may obtain the size of the file from the BB client through a message channel (not shown).

[0031] AP FEP server 140 may allocate a memory-mapped region 300 based on the file size as a transport channel to store the payload of the transferred file. In a read-from-BB operation, AP FEP server 140 may then request the BB client for the read file. The BB client may store the payload of the requested file in memory-mapped region 300 for retrieval by the AP client. In a write-to-BB operation, the AP may communicate the size of the write file to the BB client so the BB client may prepare a buffer to store the write file. AP FEP server 140 may store the payload of the write file in memory-mapped region 300 for retrieval by the BB client. When the file is successfully transferred, AP FEP server 140 may de-allocate memory-mapped region 300. If there are more files in the active session, scheduler 144 may select the next file to transfer. AP FEP server 140 may repeatedly allocate and de-allocate memory-mapped region 300 based on the size of a file until all files in the session have been successfully transferred or error conditions are encountered. In one embodiment, a file may not be transferred more than once.

[0032] AP FEP server 140 may use the aforementioned message channel to coordinate and synchronize use of the memory-mapped-based transport channel with BB 220. For example, AP FEP server 140 may use the message channel to initiate a transfer request to a BB client, obtain the size of a to-be-read file from a BB client, provide the size of a to-be-written file to a BB client, receive status of a file transfer from a BB client, etc. BB FEP server 240 of BB 220 may receive the coordination and synchronization messages to mediate the exchange of requested fdes through memory-mapped region

300 for the BB clients.

[0033] Once an active session completes its transfer, scheduler 144 may select the next session, if there is any, from session queue 142 for file transfer. In one embodiment, AP FEP server 140 may handle all error scenarios such as timeouts, transfer/checksum errors, BB-crashes, etc., in coordination with a higher layer manager. AP file server 140 may determine the corrective action to take depending on the error scenarios. For example, AP file server 140 may reset the BB and notify AP clients when there is a BB-crash. In one embodiment, an AP client may provide a timeout period for each session. The timeout period may specify the maximum amount of time the AP client is willing to wait for the session to be scheduled and all file in the session transferred. In one embodiment, the timeout period may default to 5 seconds.

[0034] FIG. 2 depicts a more detailed processing model of a file exchange mechanism mediated by AP FEP server 140 and BB FEP server 240 to transfer files between clients of the AP 120 and the BB 220 through a memory-mapped region 300 coordinated by an out-of-band message channel, according to one aspect of the disclosure. In one embodiment, the out-of-band message channel may be implemented using PCIe transport protocol. AP 120 and BB 220 may be in a wireless device of a 4G/5G network.

[0035] AP FEP server 140 may service sessions requests from AP clients including NVM synchronization client 134, PRI push client 136, and SIM transfer client 138 to exchange files with clients of BB 220. For example, NVM synchronization 134 client may request a read of the NVM image of BB 220 from NVM client 234. PRI push client 136 may request a write of the physical uplink control channel (PUCCH) resource indicator (PRI) to PRI client 236 of BB 220. SIM transfer client 138 may request a write of the SIM to SIM client 238 of BB 220. Client manager 150 may manage interactions between AP FEP server 140 and the AP clients. For example, client handler 152 may queue session requests from the AP clients for serving by AP FEP server 140. Fault handler 154 may monitor status of fde exchange of an active session to notify the AP clients of error scenarios through callback channels registered by the AP clients.

[0036] AP session manager 160 of AP FEP server 140 may implement session state machine 162 to select an active session from the session requests queued by client manager 150. In one embodiment, the scheduling algorithm may pick the first session of the AP client with the lowest number of requested sessions in the queue so as to favor AP clients that don’t generate spam sessions. In one embodiment, the scheduling algorithm may pick sessions from the AP clients in a round-robin fashion. When a session is selected, AP session manager 160 may coordinate and synchronize the exchange of the files in the active session with BB 220 through a message channel by calling AP metadata handler 170. AP metadata handler 170 may exchange coordination and synchronization messages with corresponding BB metadata handler 270 to open and close an active session, communicate metadata of fde to be exchanged, initiate and terminate a file exchange, communicate file exchange status, etc.

[0037] AP transport manager 164 of AP FEP server 140 may allocate memory-mapped region 300 to have a size equal to the size of the payload of the file to be transferred based on file metadata provided by the originating AP client or the destination BB client. For example, file metadata from the originating AP client may indicate the payload size of a write-to-BB file. For a read-from-BB file, AP FEP server 140 may request file metadata from the destination BB client through AP metadata handler 170. The destination BB client may respond with the payload size of the requested file.

[0038] In a write-to-BB operation, AP transport manager 164 may invoke write file operation 166 to write the payload of the file to memory-mapped region 300. When the file is written into memorymapped region 300, AP FEP server 140 may invoke AP metadata handler 170 to send a message requesting BB 220 to read the file from memory-mapped region 300. BB transport manager 264 of BB FEP server 240 may invoke read file operation 268 and memory driver 280 (e.g., a direct memory access (DMA) engine) to read the file in memory-mapped region 300 for writing into a buffer of the destination BB client of the write-to-BB operation.

[0039] In a read-from-BB operation, AP metadata handler 170 may send a message requesting BB 220 to write the requested file into memory-mapped region 300. BB Transport manager 264 may invoke write file operation 266 and memory driver 280 to write the requested file from a buffer of the destination BB client into memory-mapped region 300. When the requested BB file is written into memory-mapped region 300, BB FEP server 240 may invoke BB metadata handler 270 to send a message requesting AP FEP server 140 to read the file. AP transport manager 164 may invoke read file operation 168 to retrieve the BB file in memory-mapped region 300 for reading by the requesting AP client of the read-from-BB operation.

[0040] Client handler 250 of BB FEP server 240 may manage interactions between BB FEP server 240 and the BB clients. For example, client handler 250 may instruct destination BB clients to respond to the file exchange or may provide status of the file exchange to BB destination clients through callback channels registered by the BB clients. BB state machine 262 may manage the transfer of files between the buffers of destination BB clients and memory-mapped region 300 to implement the file exchange with AP 120. BB state machine 262 may also manage the exchange of coordination and synchronization messages with AP FEP server 140.

[0041] FIG. 3 is a flow diagram of a method 300 for an AP to sequence file transfers of a transfer session between the AP and a BB using dynamically allocated memory-mapped regions, according to one aspect of the disclosure. Method 300 may be practiced by the scheduler 140 or the state machine 146 of Figure 1, or by the session state machine 162 of the AP session manager 160 of Figure 2.

[0042] In operation 301, the AP examines the session queue for session requests from one or more AP clients. [0043] In operation 303, if there is no session request in the queue, the AP goes back to operation 301 to wait for session requests.

[0044] In operation 305, if there are one or more session requests in the queue, the AP selects a session request to transfer one or more files with the BB. In one embodiment, if there are multiple session requests, the AP may select the first session of an AP client with the lowest number of session requests in the queue. In one embodiment, the AP may select sessions from the AP clients in a roundrobin fashion.

[0045] In operation 307, the AP obtains metadata of a first file in the selected session from the requesting AP client or the destination BB client. For example, the AP may obtain metadata of a write- to-BB file from the requesting AP client or obtain metadata of a read-from-BB file from the destination BB client. The metadata may contain the payload size of the file.

[0046] In operation 309, the AP allocates a memory-mapped region based on the file metadata. In one embodiment, AP may allocate a memory-mapped region to have a size equal to the payload size of the file.

[0047] In operation 311, the AP initiates transfer of the file with the BB through the memorymapped region. In a read-from-BB operation, the AP may request the BB to store the file of the destination BB client in the memory-mapped region for reading by the requesting AP client. In a write- to-BB operation, the AP may store the file in the memory-mapped region for reading by the BB. The BB may write the file read from the memory-mapped region to a buffer of the destination BB client.

[0048] In operation 313, the AP waits for the file transfer to complete.

[0049] In operation 315, when the file transfer is complete, the AP de-allocates the memorymemory region for other use.

[0050] In operation 317, the AP determines if there are one or more files in the selected session to transfer. If there are one or more files, the AP repeats the operations to obtain the file metadata, allocate a memory-mapped region based on the file meta, initiate transfer of the file with the BB through the memory-mapped region, wait for the file transfer to complete, and de-allocate the memory-mapped region until all file(s) in the selected session have been transferred.

[0051] In operation 319, the AP ends the current session and selects the next session request, if there is any, in the session queue to transfer additional files with the BB.

[0052] FIG. 4 is a control flow diagram of an AP client 130 reading files of a transfer session from a BB client 230 mediated by AP FEP server 140 and BB FEP server 240 through a memory-mapped region that is allocated based on the size of files read from BB client 230, according to one aspect of the disclosure. The memory-mapped region may be used as a transport channel for the transfer session. In one embodiment, the transport channel may be implemented using PCIe transport protocol. AP FEP server 140 and BB FEP server 240 may be those in Figures 1 and 2.

[0053] In operation 410, the AP boots up. [0054] In operation 411, AP client 130 sends a request to AP FEP server 140 to register itself as an AP client and to register an AP callback channel.

[0055] In operation 420, the BB boots up.

[0056] In operation 421, BB client 230 sends a request to BB FEP server 240 to register itself as a

BB client and to register a BB callback channel.

[0057] In operation 412, AP client 130 sends a request to AP FEP server 140 to schedule a read BB session with BB client 230. For example, AP client 130 may request a transfer session that contains a fde read operation from BB client 230.

[0058] In operation 430, AP FEP server 140 schedules the read BB session for fde transfer.

[0059] In operation 431, AP FEP server 140 sends a request to BB FEP server 240 through an out- of-band message channel to start the read BB session with BB client 230. In one embodiment, the out- of-band message channel may be implemented using PCIe transport protocol.

[0060] In operation 432, BB FEP server 240 sends a notification to BB client 230 through the registered BB callback channel to inform BB client 230 of the read BB session.

[0061] In operation 433, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to acknowledge the read BB session request.

[0062] In operation 434, AP FEP server 140 sends a request to BB FEP server 240 through the message channel to identify the BB file to be read and to get the size of the BB file.

[0063] In operation 435, BB FEP server 240 sends a request to BB client 230 through the BB callback channel to obtain the size of the BB file to be read.

[0064] In operation 436, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to reply with a message containing the size of the BB file to be read.

[0065] In operation 450, AP FEP server 140 allocates memory-mapped region 300 with a size equal to the size of the BB file to be read for the file transfer.

[0066] In operation 451, AP FEP server 140 sends a request to BB FEP server 240 through the message channel to start reading the BB file.

[0067] In operation 452, BB FEP server 240 sends a request to BB client 230 through the BB callback channel to inform BB client 230 that the AP is ready to read the file.

[0068] In operation 460, BB client 230 provides a pointer to a buffer memory having a size equal to the file size of the BB file. The buffer memory stores the BB file to be read.

[0069] In operation 461, BB client 230 sends a message to BB FEP server 240 to inform BB FEP server 240 that the BB file is ready to be read.

[0070] In operation 462, BB FEP server 240 reads the BB file from the buffer memory specified by the pointer and writes the BB file to memory-mapped region 300. [0071] In operation 463, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to indicate that the BB file has been written into memory-mapped region 300.

[0072] In operation 464, BB FEP server 240 sends a message to BB client 230 through the registered BB callback channel to indicate that the BB file has been read from the buffer memory. [0073] In operation 480, BB client 230 frees the buffer memory.

[0074] In operation 453, AP FEP server 140 reads the BB file from memory-mapped region 300 into the file system of the AP. The file system of the AP may be organized separately from the memory space from which memory-mapped region 300 is allocated.

[0075] In operation 454, AP FEP server 140 sends a message to AP client 130 through the registered AP callback channel to inform AP client 130 that the requested BB file is available.

[0076] In operation 470, AP client 130 reads the BB file saved in the file system of the AP.

[0077] In operation 471, AP client 130 sends a confirmation message to AP FEP server 140 to acknowledge the completion of the read-from-BB operation.

[0078] In operation 490, AP FEP server 140 de-allocates memory-mapped region 300.

[0079] If the read BB session contains multiple read-from-BB operations, operations 434, 435, 436,

450, 451, 452, 453, 454, 460, 461, 462, 463, 464, 470, 471, 480, and 490 are repeated to read all the BB files.

[0080] In operation 491, AP FEP server 140 sends a request to BB FEP server 240 through the message channel to end the read BB session with BB client 230.

[0081] In operation 492, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to acknowledge the end of the read BB session.

[0082] In operation 493, AP FEP server 140 sends a message to AP client 130 through the registered AP callback channel to inform AP client 130 that the read BB session is complete.

[0083] FIG. 5 is a control flow diagram of an AP client 130 writing files of a transfer session to a BB client 230 mediated by AP FEP server 140 and BB FEP server 240 through a memory-mapped region that is allocated based on the size of files written to BB client 230, according to one aspect of the disclosure. The memory-mapped region may be used as a transport channel for the transfer session. In one embodiment, the transport channel may be implemented using PCIe transport protocol. AP FEP server 140 and BB FEP server 240 may be those in Figures 1 and 2.

[0084] In operation 410 the AP boots up.

[0085] In operation 411, AP client 130 sends a request to AP FEP server 140 to register itself as an AP client and to register an AP callback channel.

[0086] In operation 420, the BB boots up.

[0087] In operation 421, BB client 230 sends a request to BB FEP server 240 to register itself as a

BB client and to register a BB callback channel. [0088] In operation 413, AP client 130 sends a request to AP FEP server 140 to schedule a write BB session with BB client 230. For example, AP client 130 may request a transfer session that contains a file write operation to BB client 230.

[0089] In operation 430, AP FEP server 140 schedules the write BB session for file transfer.

[0090] In operation 437, AP FEP server 140 sends a request to BB FEP server 240 through an out- of-band message channel to start the write BB session with BB client 230. In one embodiment, the out- of-band message channel may be implemented using PCIe transport protocol.

[0091] In operation 438, BB FEP server 240 sends a notification to BB client 230 through the registered BB callback channel to inform BB client 230 of the write BB session.

[0092] In operation 439, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to acknowledge the write BB session request.

[0093] In operation 441, AP FEP server 140 sends a request to AP client 130 through the registered AP callback channel to get metadata of a write-to-BB file contained in the write BB session.

[0094] In operation 440, AP client 130 prepares the metadata of the write-to-BB file.

[0095] In operation 442, AP client 130 sends a message to AP FEP server 140 to provide the metadata including the file size of the write-to-BB file.

[0096] In operation 455, AP FEP server 140 allocates memory-mapped region 300 with a size equal to the size of the write-to-BB file and stores the write-to-BB file in memory-mapped region 300.

[0097] In operation 456, AP FEP server 140 sends a message to BB FEP server 240 through the message channel to inform BB FEP server 240 of the write BB session and to provide metadata of the write-to-BB file.

[0098] In operation 457, BB FEP server 240 sends a notification to BB client 230 through the registered BB callback channel to inform BB client 230 of the availability of the write-to-BB file and to provide the metadata including the file size of the write-to-BB file.

[0099] In operation 465, BB client 230 provides a pointer to a buffer memory having the file size of the write-to-BB file. The buffer memory will be used to store the write-to-BB file transferred from the AP.

[00100] In operation 466, BB client 230 sends a message to BB FEP server 240 to start transferring the write-to-BB file from the AP.

[00101] In operation 467, BB FEP server 240 reads the write-to-BB file from memory-mapped region 300.

[00102] In operation 475, BB FEP server 240 stores the write-to-BB file read from memory-mapped region 300 into the buffer memory.

[00103] In operation 476, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to indicate that the write-to-BB file has been read from memory-mapped region 300. [00104] In operation 477, AP FEP server 140 sends a message to AP client 130 through the registered AP callback channel to inform AP client 130 that the write-to-BB file has been transferred to the BB.

[00105] In operation 478, AP client 130 sends a message to AP FEP server 140 to close the write-to- BB operation.

[00106] In operation 490, AP FEP server 140 de-allocates memory-mapped region 300.

[00107] In operation 479, BB FEP server 240 sends a message to BB client 230 through the registered BB callback channel to indicate that the write-to-BB file has been stored into the buffer memory.

[00108] In operation 485, BB client 230 processes the write-to-BB file in the buffer memory.

[00109] If the write BB session contains multiple write-to-BB operations, operations 440, 441, 442, 455, 456, 457, 465, 466, 467, 475, 476, 477, 478, 479, 485, and 490 are repeated to write all files to BB. [00110] In operation 494, AP FEP server 140 sends a request to BB FEP server 240 through the message channel to end the write BB session with BB client 230.

[00111] In operation 495, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to acknowledge the end of the write BB session.

[00112] In operation 496, AP FEP server 140 sends a message to AP client 130 through the registered AP callback channel to inform AP client 130 that the write BB session is complete.

[00113] FIG. 6 is a control flow diagram of an AP client 130 requesting file transfer sessions with a BB client 230 as scheduled by AP file exchange server 140 using dynamically allocated memorymapped regions as a transport channel to BB FEP server 240, according to one aspect of the disclosure. [00114] In operation 615, the BB boots up.

[00115] In operation 620, AP FEP server 140 is initialized.

[00116] In operation 625, BB FEP server 240 is initialized and waits for a transfer session.

[00117] In operation 630, AP FEP server 140 are BB FEP server 240 are ready to exchange files.

[00118] In operation 631, AP client 130 receives a request for file exchange from a higher-layer client.

[00119] In operation 632, AP client 130 creates a transfer session object and sends a request to AP FEP server 140 to schedule a transfer session with BB client 230. The transfer session may schedule a combination of one or more read-from-BB file transfers and one or more write-to-BB files transfers. AP EP server 140 may serialize the transfer session request from AP client 130 with transfer sessions requested by other AP clients in a queue.

[00120] In operation 635, AP FEP server 140 selects the transfer session requested by AP client 130 from the queue as an active transfer session. [00121] In operation 636, AP FEP server 140 sends a request to BB FEP server 240 through a message channel to start the transfer session with BB client 230.

[00122] In operation 637, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to acknowledge the transfer session request.

[00123] In operation 640, AP FEP server 140 transfers all read-from-BB files and write-to-BB files in the active transfer session by exchanging requested files with BB client 230 using dynamically allocated memory-mapped regions as FEP transport channel 610. Operation 640 includes operation 638 where AP FEP server 140 opens FEP transport channel 610 by allocating memory-mapped regions for the file exchange. Operation 640 includes operation 639 where AP FEP server 140 closes FEP transport channel 610 by de-allocating memory-mapped regions after completing the file exchange.

[00124] In operation 686, AP FEP server 140 sends a request to BB FEP server 240 through the message channel to end the transfer session with BB client 230.

[00125] In operation 687, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to acknowledge the end of the transfer session.

[00126] In operation 688, AP FEP server 140 sends a message to AP client 130 to inform AP client 130 that the transfer session with BB client 230 is complete.

[00127] In operation 690, AP FEP server 140 and BB FEP server 240 close the transfer session.

[00128] FIG. 7 is a control flow diagram of AP FEP server 140 dynamically allocating memorymapped regions as transport channel 610 to read files requested by AP client 130 from BB client 230 through BB FEP server 240 based on the read file size, according to one aspect of the disclosure. FIG. 7 represents operation 640 of FIG. 6 for transferring read-from-BB files in an active transfer session using dynamically allocating memory-mapped regions.

[00129] In operation 641, AP FEP server 140 sends a read request to BB FEP server 240 through a message channel to identify the BB file to be read and to get file metadata including the size of the BB file.

[00130] In operation 642, BB FEP server 240 sends the request for the read-from-BB file to BB client 230 to obtain the file metadata including the size of the read-from-BB file.

[00131] In operation 643, BB client 240 sends the file metadata including the size of the read-from- BB file to BB FEP server 240.

[00132] In operation 644, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to reply with a message containing file metadata including the size of the read-from- BB file.

[00133] In operation 645, AP FEP server 140 opens transport channel 610 based on the file metadata including the size of the read-from-BB file. [00134] In operation 650, AP FEP server 140 allocates a memory-mapped region with a size equal to the size of the read-from-BB file for transferring the BB file.

[00135] In operation 651, AP FEP server 140 sends a request to BB FEP server 240 through the message channel to start reading the BB file.

[00136] In operation 652, BB FEP server 240 sends a message to BB client 230 notifying BB client 230 that BB FEP server 240 is ready to transfer the BB file.

[00137] In operation 653, BB client 230 sends a response to BB FEP server 240 acknowledging that the BB file is ready to be read.

[00138] In operation 654, BB FEP server 240 reads the BB file and writes the read-from-BB file into the memory-mapped region.

[00139] In operation 655, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to indicate that the read-from-BB file has been placed in the memory-mapped region.

[00140] In operation 656, AP FEP server 240 reads the BB file from the memory-mapped region and stores the read-from-BB file into a buffer region of the AP memory system that is accessible by AP client 130.

[00141] In operation 657, AP FEP server 240 closes transport channel 610 by de-allocating the memory-mapped region.

[00142] In operation 658, AP FEP server 140 sends a message to AP client 130 to inform AP client 130 that the read of the BB file is complete and the read-from-BB file is accessible from the buffer region of the AP memory system.

[00143] FIG. 8 is a control flow diagram of AP FEP server 140 dynamically allocating memorymapped regions as transport channel 610 to write files requested by AP client 130 to BB client 130 through BB FEP server 240 based on the write file size, according to one aspect of the disclosure. FIG.

8 represents operation 640 of FIG. 6 for transferring write-to-BB files in an active transfer session using dynamically allocating memory-mapped regions.

[00144] In operation 661, AP FEP server 140 sends a write request to BB FEP server 240 through a message channel to identify the file to be written to BB client 230 and to provide file metadata including the size of the write-to-BB file.

[00145] In operation 662, BB FEP server 240 sends the write request to BB client 230 to notify BB client 230 of the write-to-BB file and to provide file metadata including the size of the write-to-BB file.

[00146] In operation 663, BB client 230 sends a response to BB FEP server 240 to inform BB FEP server 240 that BB client 230 is ready to receive the write-to-BB file.

[00147] In operation 664, BB FEP server 240 sends a response to AP FEP server 140 through the message channel acknowledging the write request. [00148] In operation 665, AP FEP server 140 opens transport channel 610 based on the file metadata including the size of the write-to-BB file.

[00149] In operation 670, AP FEP server 140 allocates a memory-mapped region with a size equal to the size of the write-to-BB file for transferring the file.

[00150] In operation 671, AP FEP server 140 stores the write-to-BB file in the memory-mapped region.

[00151] In operation 672, AP FEP server 140 sends a message to BB FEP server 240 through the message channel to indicate that the write-to-BB file has been placed in the memory-mapped region and is available for reading by BB FEP server 240.

[00152] In operation 673, BB FEP server 240 reads the write-to-BB file from the memory-mapped region and stores the write-to-BB file into a part of the BB memory system that is accessible by BB client 230.

[00153] In operation 674, BB FEP server 240 sends a message to BB client 230 to indicate that the write-to-BB file has been read from the memory-mapped region and is accessible by BB client 230.

[00154] In operation 675, BB FEP server 240 sends a response to AP FEP server 140 through the message channel to indicate that the write-to-BB file has been read from the memory-mapped region.

[00155] In operation 676, AP FEP server 240 closes transport channel 610 by de-allocating the memory-mapped region.

[00156] In operation 677, AP FEP server 140 sends a message to AP client 130 to inform AP client 130 that the write-to-BB file has been written into BB client 230.

[00157] FIG. 9 is a flow diagram of a method 900 for a first processor to exchange a file with a second processor using a dynamically allocated memory-mapped region as a transport channel coordinated by a message channel, according to one aspect of the disclosure. Method 900 may be practiced by the AP FEP server 140 and the BB FEP server 240 of Figures 1, 2, 4, 5, 6, 7, or 8.

[00158] In operation 901, the first processor receives a request from a client of the first processor to exchange a file with the second processor. In one embodiment, the file may be exchanged with a client of the second processor.

[00159] In operation 903, the first processor exchanges metadata of the file with the second processor through a message channel. In one embodiment, the metadata may include information such as the size of the payload of the file to be exchanged.

[00160] In operation 905, the first processor allocates a memory-mapped region as a transport channel based on the metadata of the file. In one embodiment, the first processor allocates the memorymapped region to be the pay load size of the file to be exchanged.

[00161] In operation 907, the first processor coordinates with the second processor through the message channel a transfer of the file to be exchanged. In one embodiment, the message channel may be an out-of-band message channel separate from the transport channel used for the payload of the file exchanged.

[00162] In operation 909, first processor transfers to the second processor or transfers from the second processor the file through the transport channel provided by the memory-mapped region. In one embodiment, the file transferred includes undivided content of the file. In one embodiment, the file exchange operation may include the first processor reading the file from the second processor or the first processor writing the file to the second processor through the memory-mapped region.

[00163] In operation 911, the first processor de-allocates the memory-mapped region.

[00164] Aspects of the file exchange system described herein may be implemented in a data processing system, for example, by a smartphone, tablet computer, laptop computer, desktop computer, other consumer electronic devices, a network computer, network server, or other data processing systems. In particular, the operations described are signal processing operations performed by a processor that is executing instructions stored in one or more memories. The processor may read the stored instructions from the memories and execute the instructions to perform the operations described. These memories represent examples of machine readable non-transitory storage media that can store or contain computer program instructions which when executed cause a data processing system to perform the one or more methods described herein. The processor may be a processor in a local device such as a smartphone, a processor in a remote server, or a distributed processing system of multiple processors in the local device and remote server with their respective memories containing various parts of the instructions needed to perform the operations described.

[00165] The processes and blocks described herein are not limited to the specific examples described and are not limited to the specific orders used as examples herein. Rather, any of the processing blocks may be re-ordered, combined or removed, performed in parallel or in serial, as necessary, to achieve the results set forth above. The processing blocks associated with implementing the file exchange system may be performed by one or more programmable processors executing one or more computer programs stored on a non-transitory computer readable storage medium to perform the functions of the system. All or part of the file exchange system may be implemented as, special purpose logic circuitry (e.g., an FPGA (field-programmable gate array) and/or an ASIC (application-specific integrated circuit)). All or part of the file exchange system may be implemented using electronic hardware circuitry that include electronic devices such as, for example, at least one of a processor, a memory, a programmable logic device or a logic gate. Further, processes can be implemented in any combination hardware devices and software components.

[00166] While certain exemplary instances have been described and shown in the accompanying drawings, it is to be understood that these are merely illustrative of and not restrictive on the broad disclosure, and that this disclosure is not limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those of ordinary skill in the art. The description is thus to be regarded as illustrative instead of limiting.

[00167] To aid the Patent Office and any readers of any patent issued on this application in interpreting the claims appended hereto, applicants wish to note that they do not intend any of the appended claims or claim elements to invoke 35 U.S.C. 112(f) unless the words “means for” or “step for” are explicitly used in the particular claim.

Claims

CLAIMS What is claimed is:

1. A method for a first processor to exchange files with a second processor, the method comprising: receiving, by the first processor from a client, a request to exchange a file with a second processor; exchanging, by the first processor with the second processor through a message channel, metadata of the file; allocating, by the first processor, a memory-mapped region as a transport channel based on the metadata of the file; coordinating, by the first processor with the second processor through the message channel, a transfer of the file; transferring, by the first processor to the second processor, or by the first processor from the second processor, the file through the transport channel; and de-allocating, by the first processor, the memory-mapped region.

2. The method of claim 1, wherein the request includes one or more files and wherein receiving by the first processor the request from the client comprises: queuing by the first processor the request in a queue that includes one or more other requests; and selecting by the processor the request from the queue to transfer the one or more files one file at a time.

3. The method of claim 2, wherein the one or more files in the queue are transferred before selecting by the first processor any of the other requests for file transfer.

4. The method of claim 1, wherein the metadata comprises a size of a payload of the file.

5. The method of claim 4, wherein allocating by the first processor the memory-mapped region comprises: allocating by the first processor the memory-mapped region to have a size equal to the size of the payload of the file.

6. The method of claim 1, wherein transferring the file through the transport channel comprises: reading by the first processor from the second processor an undivided payload of the file through the memory-mapped region; or writing by the first processor to the second processor an undivided payload of the file through the memory-mapped region.

7. The method of claim 1, wherein the message channel is a separate channel from the transport channel.

8. The method of claim 1, wherein the request to exchange the fde with the second processor comprises a request to read the fde from the second processor, wherein exchanging the metadata of the fde comprises: receiving by the first processor from the second processor the metadata of the fde through the message channel, and wherein transferring the fde through the transport channel comprises: reading by the first processor from the second processor the fde through the memory-mapped region for access by the client.

9. The method of claim 1, wherein the request to exchange the fde with the second processor comprises a request to write the fde to the second processor, wherein exchanging the metadata of the fde comprises: transmitting by the first processor to the second processor the metadata of the fde through the message channel; and wherein transferring the fde through the transport channel comprises: writing by the first processor to the second processor the fde through the memory-mapped region for access by a client of the second processor.

10. The method of claim 1, wherein coordinating the transfer of the fde comprises: handling, by the first processor, error conditions when the transfer of the fde is unsuccessful.

11. The method of claim 1, wherein the transport channel comprises a peripheral component interconnect express (PCIe) transport channel.

12. A device comprising: one or more clients; a processor; and a memory coupled to the processor to store instructions, which when executed by the processor, cause the processor to: receive from one of the clients a request to exchange a fde with a second processor; exchange with the second processor metadata of the fde through a message channel; allocate a memory-mapped region as a transport channel based on the metadata of the fde; coordinate with the second processor through the message channel a transfer of the file; transfer the file to the second processor or from the second processor through the transport channel; and de-allocate the memory-mapped region.

13. The device of claim 12, wherein the request includes one or more files and wherein to receive the request from one of the clients, the processor further executes the instructions to: queue the request in a queue that includes one or more other requests; and select the request from the queue to transfer the one or more files one file at a time.

14. The device of claim 13, wherein the one or more files in the queue are transferred before the processor further executes the instructions to select any of the other requests for file transfer.

15. The device of claim 12, wherein the metadata comprises a size of a payload of the file.

16. The device of claim 15, wherein to allocate the memory-mapped region, the processor further executes the instructions to: allocate the memory-mapped region to have a size equal to the size of the payload of the file.

17. The device of claim 12, wherein to transfer the file through the transport channel, the processor further executes the instructions to: read from the second processor an undivided payload of the file through the memory-mapped region; or write to the second processor an undivided payload of the file through the memory-mapped region.

18. The device of claim 12, wherein the request to exchange the file with the second processor comprises a request to read the file from the second processor, wherein to exchange the metadata of the file, the processor further executes the instructions to: receive from the second processor the metadata of the file through the message channel, and wherein to transfer the file through the transport channel, the processor further executes the instructions to: read the file from the second processor through the memory-mapped region for access by the client that generates the request.

19. The device of claim 12, wherein the request to exchange the file with the second processor comprises a request to write the file to the second processor, wherein to exchange the metadata of the file, the processor further executes the instructions to: transmit to the second processor the metadata of the file through the message channel, and wherein to transfer the file through the transport channel, the processor further executes the instructions to: write the file to the second processor through the memory-mapped region for access by a client of the second processor.

20. A non-transitory computer-readable medium having instructions stored therein, which when executed by a processor, cause the processor to perform operations comprising: receive from a client a request to exchange a file with a second processor; exchange with the second processor metadata of the file through a message channel; allocate a memory-mapped region as a transport channel based on the metadata of the file; coordinate with the second processor through the message channel a transfer of the file; transfer the file to the second processor or from the second processor through the transport channel; and de-allocate the memory-mapped region.