[Roadmap] Payload Transfer in TransferQueue
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- python
- Ambito
- backend, distributed-systems, networking, performance
Direzione di ricerca
Inizia scegliendo un elemento della roadmap non ancora spuntato e rivedendo l’astrazione Payload Transfer esistente e la PR #163. Commenta prima di iniziare per coordinare il lavoro, quindi definisci l’ambito dell’elemento selezionato e l’approccio alla validazione. Il lavoro è completo quando l’elemento scelto è implementato e la sua correttezza, stabilità o performance è stata validata in modo appropriato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
This roadmap tracks the development of Payload Transfer in TransferQueue. Feedback, discussion, and contributions are welcome.
If you plan to work on an item, please comment below before starting to help coordinate the work and avoid duplication.
Foundation
-
Payload Transfer abstraction and NIXL-UCX backend
Introduce the Payload Transfer abstraction and the initial NIXL-UCX PUT/GET data path, while keeping ZMQ as the control plane and default payload path.
Reliability
- Improve transfer lifecycle management
Safely manage MR, buffers, pending state, and peer metadata across PREPARE, CANCEL, transfer failure, retry, and cleanup paths.
Performance
-
Optimize buffer pooling and memory registration
Reduce buffer allocation and memory registration overhead through better reuse. -
Reduce unnecessary data copies
Remove avoidable copies in the receive path and process data directly from registered buffers where possible. -
Improve payload transfer concurrency
Avoid serializing independent transfers through a single send executor (for example,max_workers=1) when one manager communicates with multiple StorageUnits, and avoid blocking the StorageUnit control worker while waiting for long-running NIXL GET transfers to complete. Preserve transfer lifecycle correctness while allowing concurrent data-plane progress and reducing head-of-line blocking in RL workloads.
Backend Expansion
- Add more Payload Transfer backends
Extend the abstraction to support additional backends such as HIXL.
Validation
- Expand correctness, stability, and performance validation
Cover larger-scale, sustained, and multi-node workloads.
Documentation
- Complete user-facing tutorials and documentation
Add usage guides, configuration examples, and related feature documentation.
Mainline Integration
- Prepare for integration into
main
Move toward mainline integration once the feature is sufficiently stable and validated.
- Lingua principale
- Python
- Stelle
- 166
- Fork
- 56
- Merge medio
- 4g 1h
- PR unite (30g)
- 15
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Ascend/TransferQueue
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
Ascend/TransferQueue#194 ·
I maintainer di solito rispondono entro 1 giorno
-
[doc] Document the contract of storage-side callables (data_parser, merge_fn) with a tutorialAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
Ascend/TransferQueue#195 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
Ascend/TransferQueue#188 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
Ascend/TransferQueue#180 ·
I maintainer di solito rispondono entro 1 giorno
-
[optim] MooncakeStore read path registers RDMA buffers on every get(), dominating end-to-end timeForse di nuovo libera @weiziyoung l’ha presa 38 giorni fa e non c’è nessuna pull request aperta. Apertaenhancement
Ascend/TransferQueue#169 · 3 commenti · 1 reazione · 2 assegnatari ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Ascend/TransferQueue
Issue simili
-
Python Volcengine provider returns failures instead of raising themForse già presa @Ricardo-M-L l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
agent-infra/sandbox#248 ·
-
Textractor leaves empty temporary files when remote retrieval failsForse già presa @HuaTNA l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
test(bm_generation): pin the learning parameters and CPU sync shortcutForse già presa @iloveeyjafjalla l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
qboson/kaiwu-pytorch-plugin#1341 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
elder-plinius/V3R1T4S#625 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
foxglove/mcap#1907 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno