Zerocopy post API: posting a buffer smaller than the source is allowed but unreported; larger is unchecked on the host path. Decide the contract.

Aperta
  • Qualcosa non va?
#3,989 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

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
22/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
distributed-systems, hpc

Direzione di ricerca

This is an API-contract decision, not a first-timer patch. Read the CkPostBuffer manual entry and the host vs device paths named in the issue (CkRdmaDeviceIssueRgets, performEmApiRget, p2p completion). Compare with tests/charm++/zerocopy/zc_post_modify_size and the reconverse#223 RMA overrun. Done means the group agrees whether posted size may be a prefix, then abort-on-larger and documented size-argument behaviour (or equal-size-only plus test invert) are implemented consistently.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Raised while fixing reconverse#223 (the RMA path ignored the posted size and overran the receiver's buffer). The fix restores the documented contract of CkPostBuffer, whose manual entry says the posted size "should be always smaller than or equal to the size of the source buffer": the receiver may take a prefix of the source. Three things about that contract deserve a decision and, at least, documentation:

  1. Posted size larger than the source is undefined and unchecked on the host path. The manual says "should"; the device path aborts (CkRdmaDeviceIssueRgets: posted data size is larger than source data size), the host path does not. It should abort at the post, since the receiver would otherwise read uninitialised tail as if delivered. (Being added on the reviewed line alongside the reconverse fix.)

  2. Nobody is told how much was transferred. After a shorter post the regular entry method's size argument still carries the sender's count on the paths read so far (performEmApiRget, the p2p completion), so a receiver that did not itself remember what it posted walks past the transferred bytes; the sender is never informed either. Either the runtime should hand the regular entry method the transferred (posted) size, or the manual must say the size argument is the sender's and the receiver must use its own record of the post.

  3. Is "receiver takes a prefix" worth keeping at all? It is hard to state a use case: the sender chose to send N bytes; a receiver wanting fewer can post a full-size buffer and ignore the tail, at the cost of memory, or the sender can be told to send less. Kale's view (2026-09-17): hard to find a rationale. If the group agrees, the contract becomes "posted size must equal the source size", the runtime aborts otherwise, and tests/charm++/zerocopy/zc_post_modify_size is retired or inverted to test the abort. Classic Charm++ would keep the old behaviour unless changed there too.

Until 3 is decided, 1 and 2 are the minimum: abort on larger, document the size argument.

🤖 Generated with Claude Code

Lingua principale
C++
Stelle
241
Fork
62
Merge medio
1g 1h
PR unite (30g)
121

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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di charmplusplus/charm

Tutte le issue di charmplusplus/charm

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.