storage: storvsc user-mode implementation #1256
Conversation
| struct StorvscInner { | ||
| next_transaction_id: AtomicU64, | ||
| new_request_receiver: Receiver<StorvscRequest>, | ||
| transactions: Mutex<HashMap<u64, PendingOperation>>, |
There was a problem hiding this comment.
I would use a slab::Slab<PendingOperation> instead of a HashMap. The slab will give you a usize key which you can use as the transaction ID.
There was a problem hiding this comment.
I see from the Slab docs that it can reuse keys for removed items. Could there be any issues with reused, non-sequential keys on the storvsp side?
There was a problem hiding this comment.
That would be a protocol violation--storvsp can only send a completion for a transaction once.
There was a problem hiding this comment.
So does slab still work for this if it can reuse keys, given that it can result in duplicate transaction IDs?
| .0 | ||
| .to_owned(); | ||
|
|
||
| // Step 4: CREATE_SUB_CHANNELS (if supported) |
There was a problem hiding this comment.
We don't really support subchannels yet, right?
There was a problem hiding this comment.
Subchannels are seemingly supported by our storvsp implementation.
|
|
||
| enum Packet { | ||
| Completion(StorvscCompletionPacket), | ||
| //Data(StorvscDataPacket), |
There was a problem hiding this comment.
I believe this case will be necessary for supporting hot add/remove.
There was a problem hiding this comment.
What would the protocol operations be for hot add/remove?
There was a problem hiding this comment.
The driver get an async notification message that something changed, and then it's supposed to rescan the SCSI bus (if even needs to--in the OpenHCL case, we know what LUN to expect, so we can pretty much just silently drop the notification).
There was a problem hiding this comment.
After doing nothing, then we need to send a completion for the data packet, correct?
|
Looking good! |
This is an implementation of the storvsc (client complement to storvsp) for SCSI storage over VMBus.
#273