Introduce per-device completion queue pools
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v3 Latest posting 4/40 of 9 patches 0 repliesNew
- v3 posting 3/41 of 9 patches 0 repliesSuperseded
- v3 posting 2/41 of 9 patches 0 repliesSuperseded
Earlier versions · 1
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v3 posting 1/4 | 0 of 9 patches | 0 replies | Superseded |
Patches in v3 posting 4/4 No applies recorded yet
None of the 9 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v3 yet.
Cover letter [PATCH v3 0/9] Introduce per-device completion queue pools
Quoted 9 lines · Jason Gunthorpe
Quoted 8 lines · Sagi Grimberg
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
It is too bad we can't re-size CQs.. Can we?
I wish we could, but its an optional feature so I can't see how we can use it.
Well, it looks like mlx4/5 can do it, which covers a huge swath of deployed hardware..
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
I'd say make an optimal implementation using
resize_cqand just a working implementation without it?I can experiment with it, sure. Do you think that its a must have for first phase though?
Not clear to me.. Bart?
Hi Jason,
Having the completion queue pool implementation use resize_cq internally if supported by the HCA sounds interesting to me. This would help to avoid that the CQ pool implementation uses more memory than needed. Sagi, if you don't have the time to work on this please let me know. In that case I will try to free up some time and implement this myself.
Bart.