Overhaul block device interfaces #549
Conversation
|
I'm still working on additional testing for this, but I wanted to get it posted so folks could look through it at their leisure. |
| #[usdt::provider(provider = "propolis")] | ||
| mod probes { |
There was a problem hiding this comment.
Thanks for the new device generic probes!
Also ++ on the complete probes providing timing themselves. Definitely beats the more error prone manual approach in a dtrace script. (Good bye results tainted by "dynamic variable drops"; you will not be missed 😭)
There was a problem hiding this comment.
There's still the hassle of requiring both begin/complete probes if you want sizing or offset information about the operations, but I think that's an acceptable compromise, rather than having an excessive argument list for the completion probes.
An open question following the integration of this work: Should some or all of the per-device probes (nvme, virtio, etc) be stripped out, since the block-generic ones cover most of those needs?
There was a problem hiding this comment.
I do think per-device probes can be useful for correlating against in-guest operations with queue ids, command ids, etc
This reshapes how block devices (frontends) interact with their attached backends. Rather than associating a backend with a device when it is created, backend and device are attached after the fact, when each has had an opportunity to be initialized. Through its attachment handle, the device is able to notify the backend of new requests, but also query sizing parameters (previously specified during device construction), pause and unpause request retrieval, and (in the future) perform other tasks such as cache mode alteration. The backend has a corresponding attachment handle through which it retrieves pending requests from the device -- behavior which is largely unchanged from the original structure. Rather than store device-specific information required to issue request completions to the guest, the device emulation is expecting to use a `Tracking` structure which will store the completion data to be retrieved using an ID injected into the Request, which is passed back with its result when processed by the backend. This tracking structure also implements several generic USDT probes for tracing block events, rather than requiring the use of per-device probes.
pfmooney
force-pushed
the
block-rework
branch
from
c161858 to
6a64a51
Compare
This reshapes how block devices (frontends) interact with their attached backends. Rather than associating a backend with a device when it is created, backend and device are attached after the fact, when each has had an opportunity to be initialized.
Through its attachment handle, the device is able to notify the backend of new requests, but also query sizing parameters (previously specified during device construction), pause and unpause request retrieval, and (in the future) perform other tasks such as cache mode alteration.
The backend has a corresponding attachment handle through which it retrieves pending requests from the device -- behavior which is largely unchanged from the original structure.
Rather than store device-specific information required to issue request completions to the guest, the device emulation is expecting to use a
Trackingstructure which will store the completion data to be retrieved using an ID injected into the Request, which is passed back with its result when processed by the backend. This tracking structure also implements several generic USDT probes for tracing block events, rather than requiring the use of per-device probes.