|
74 | 74 | /// | |
75 | 75 | /// ... ---+ |
76 | 76 | /// |
77 | | -/// |
78 | | -/// Memory management |
79 | | -/// |
80 | 77 | /// The library can be used either with a regular heap (preferably constant-time) or with a collection of fixed-size |
81 | 78 | /// block pool allocators (in safety-certified systems). It is up to the application to choose the desired memory |
82 | 79 | /// management strategy; the library is interfaced with the memory managers via a special memory resource abstraction. |
83 | 80 | /// |
84 | 81 | /// Typically, if block pool allocators are used, the following block sizes should be served: |
85 | 82 | /// |
86 | | -/// - MTU sized blocks for the TX and RX pipelines (usually less than 2048 bytes); |
87 | | -/// - TX fragment item sized blocks for the TX pipeline (less than 128 bytes). |
88 | | -/// - RX session object sized blocks for the RX pipeline (less than 512 bytes); |
89 | | -/// - RX fragment handle sized blocks for the RX pipeline (less than 128 bytes). |
90 | | -/// - udpard_remote_t sized blocks for the return path discovery. |
| 83 | +/// - MTU sized blocks for the TX and RX pipelines (typically at most 1.5 KB unless jumbo frames are used). |
| 84 | +/// - sizeof(udpard_tx_item_t) blocks for the TX pipeline. |
| 85 | +/// - sizeof(rx_session_t) blocks for the RX pipeline. |
| 86 | +/// - sizeof(udpard_fragment_t) blocks for the RX pipeline. |
91 | 87 | /// |
92 | 88 | /// -------------------------------------------------------------------------------------------------------------------- |
93 | 89 | /// |
@@ -233,10 +229,10 @@ typedef struct udpard_mem_resource_t |
233 | 229 | /// as well as the payload structure itself, assuming that it is also heap-allocated. |
234 | 230 | /// The model is as follows: |
235 | 231 | /// |
236 | | -/// (payload header) ---> udpard_fragment_t: |
237 | | -/// next ---> udpard_fragment_t... |
238 | | -/// origin ---> (the free()able payload data buffer) |
239 | | -/// view ---> (somewhere inside the payload data buffer) |
| 232 | +/// udpard_fragment_t: |
| 233 | +/// next ---> udpard_fragment_t... |
| 234 | +/// origin ---> (the free()able payload data buffer) |
| 235 | +/// view ---> (somewhere inside the payload data buffer) |
240 | 236 | /// |
241 | 237 | /// Payloads of received transfers are represented using this type, where each fragment corresponds to a frame. |
242 | 238 | /// The application can either consume them directly or to copy the data into a contiguous buffer beforehand |
@@ -427,6 +423,9 @@ bool udpard_tx_new(udpard_tx_t* const self, |
427 | 423 | /// The MTU of the generated datagrams is dependent on the value of the MTU setting at the time when this function |
428 | 424 | /// is invoked. The MTU setting can be changed arbitrarily between invocations. |
429 | 425 | /// |
| 426 | +/// The topic hash is not defined for P2P transfers since there are no topics involved; in P2P, this parameter |
| 427 | +/// is used to pass the destination node's UID instead. |
| 428 | +/// |
430 | 429 | /// The transfer_id parameter will be used to populate the transfer_id field of the generated datagrams. |
431 | 430 | /// The caller shall increment the transfer-ID counter after each successful invocation of this function |
432 | 431 | /// per redundant interface; the same transfer published over redundant interfaces shall have the same transfer-ID. |
@@ -456,31 +455,16 @@ bool udpard_tx_new(udpard_tx_t* const self, |
456 | 455 | /// |
457 | 456 | /// The time complexity is O(p + log e), where p is the amount of payload in the transfer, and e is the number of |
458 | 457 | /// transfers (not frames) already enqueued in the transmission queue. |
459 | | -uint32_t udpard_tx_publish(udpard_tx_t* const self, |
460 | | - const udpard_us_t now, |
461 | | - const udpard_us_t deadline, |
462 | | - const udpard_prio_t priority, |
463 | | - const uint64_t topic_hash, |
464 | | - const uint32_t subject_id, |
465 | | - const uint64_t transfer_id, |
466 | | - const udpard_bytes_t payload, |
467 | | - const bool ack_required, |
468 | | - void* const user_transfer_reference); |
469 | | - |
470 | | -/// Similar to udpard_tx_publish, but for P2P transfers between specific nodes. |
471 | | -/// This can only be sent in a response to a published message; the RX pipeline will provide the discovered return |
472 | | -/// endpoint for this particular remote node. |
473 | | -/// The destination UID may seem redundant but it is needed to filter out incorrectly addressed transfers. |
474 | | -uint32_t udpard_tx_p2p(udpard_tx_t* const self, |
475 | | - const udpard_us_t now, |
476 | | - const udpard_us_t deadline, |
477 | | - const udpard_prio_t priority, |
478 | | - const uint64_t remote_uid, |
479 | | - const udpard_udpip_ep_t remote_ep, |
480 | | - const uint64_t transfer_id, |
481 | | - const udpard_bytes_t payload, |
482 | | - const bool ack_required, |
483 | | - void* const user_transfer_reference); |
| 458 | +uint32_t udpard_tx_push(udpard_tx_t* const self, |
| 459 | + const udpard_us_t now, |
| 460 | + const udpard_us_t deadline, |
| 461 | + const udpard_prio_t priority, |
| 462 | + const uint64_t topic_hash, // For P2P transfers, this is the destination's UID. |
| 463 | + const udpard_udpip_ep_t remote_ep, |
| 464 | + const uint64_t transfer_id, |
| 465 | + const udpard_bytes_t payload, |
| 466 | + const bool ack_required, |
| 467 | + void* const user_transfer_reference); |
484 | 468 |
|
485 | 469 | /// Purges all timed out items from the transmission queue automatically; returns the next item to be transmitted, |
486 | 470 | /// if there is any, otherwise NULL. The returned item is not removed from the queue; use udpard_tx_pop() to do that. |
|
0 commit comments