nvme: NUMA locality for fabrics
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v3 Latest posting 4/40 of 3 patches 0 repliesNew
- v3 posting 3/40 of 3 patches 0 repliesSuperseded
- v3 posting 2/40 of 3 patches 0 repliesSuperseded
Earlier versions · 3
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v3 posting 1/4 | 3 patches | 0 replies | Superseded | |
| v2 | 3 patches | 0 replies | Superseded | |
| v1 | 2 patches | 0 replies | Superseded |
Patches in v3 posting 4/4 No applies recorded yet
None of the 3 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 [PATCHv3 0/3] nvme: NUMA locality for fabrics
Quoted 9 lines · Christoph Hellwig
Quoted 4 lines · Hannes Reinecke
Fully agreed here.
It all comes down to the link latency.
If the link latency is the main bottleneck multipathing will benefit from round-robin (or any I/O scheduler, for that matter).It still makes a lot more sense to try to have queues with an affinity to a given path rather than doing round robin IFF you care about latency.
That's what I tried initially, but the implementation and the distribution algorithm turned out the be far from simple.
Quoted 3 lines
If you latency sucks anyway round robing makes sense. But why do you use nvme on such a horrible interconnect anyway?
Hmm.
Because the target implements it?
And I didn't control the target implementation in this case?
Quoted 6 lines
Quoted 3 lines
And this it not just relevant for 'legacy' hardware; I've seen a performance benefit on a 32G FC setup, which is pretty much state of the art currently.
Well, FC is legacy no matter which link speed.
Oh, for crying out loud.
If you can't be bothered to support FC-NVMe, fine, you don't have to. But others might, and might not be so fortunate as to have a choice about _what_ they want to support.
Hannes