virtio — archive

[PATCH v2 0/6] rework notifications terminology

From: Halil Pasic <[email protected]>
To: [email protected]
Date: Wed, 13 Jun 2018 13:15:00 -0000

On 06/13/2018 11:44 AM, Cornelia Huck wrote: > On Mon, 11 Jun 2018 18:11:53 +0200 > Halil Pasic <[email protected]> wrote: > >> Let us unify the wording when talking about notifications. This change >> establishes the terms available buffer notification for what was usually >> simply called notification or virtqueue notification in v1.0 and used >> buffer notification for what was usually called interrupt. >> >> The term configuration change notification in kept where called so and >> consolidated where it's called configuration change interrupt or >> similar. >> >> The changes done here are limited to the core part, and don't >> conceptually involve neither the transports nor the devices (references >> are updated though). Future changes should address these parts. >> >> Signed-off-by: Halil Pasic <[email protected]> >> --- >> cl-os.tex | 2 +- >> conformance.tex | 8 +++--- >> content.tex | 26 +++++++++++ -------- >> packed-ring.tex | 61 ++++++++++++++++++++++++++ -------------------- >> split-ring.tex | 72 ++++++++++++++++++++++++++++++++ ----------------------- >> 5 files changed, 96 insertions(+), 73 deletions(-) >> > >> diff --git a/content.tex b/content.tex >> index be18234..e1dcaea 100644 >> --- a/content.tex >> +++ b/content.tex > > (...) > >> @@ -388,10 +391,11 @@ reads unless notified. >> >> \subsection{Notification of Device Configuration Changes}\label{sec:General Initialization And Device Operation / Device Operation / Notification of Device Configuration Changes} >> >> -For devices where the device-specific configuration information can be changed, an >> -interrupt is delivered when a device-specific configuration change occurs. >> +For devices where the device-specific configuration information can be >> +changed, a configuration change notification is delivered when a > > Perhaps better "is sent", to keep in line with the used/available > buffer notifications? > I agree, it sounds better. I kept 'delivered' without thinking about it. I will change this for v3. >> +device-specific configuration change occurs. >> >> -In addition, this interrupt is triggered by the device setting >> +In addition, this notification is triggered by the device setting >> DEVICE_NEEDS_RESET (see \ref{sec:Basic Facilities of a Virtio Device / Device Status Field / DEVICENEEDSRESET}). >> >> \section{Device Cleanup}\label{sec:General Initialization And Device Operation / Device Cleanup} > > (...) > >> @@ -309,22 +310,20 @@ in the ring. >> >> \subsection{Driver and Device Event Suppression} >> \label{sec:Packed Virtqueues / Driver and Device Event Suppression} >> -In many systems driver and device notifications involve >> +In many systems used and available buffer notifications involve >> significant overhead. To mitigate this overhead, >> each virtqueue includes two identical structures used for >> controlling notifications between the device and the driver. >> >> The Driver Event Suppression structure is read-only by the >> -device and controls the events sent by the device >> -to the driver (e.g. interrupts). >> +device and controls the used buffer notifications (sent by the device >> +to the driver). > > Drop the brackets? > Can do (if nobody complains). >> >> The Device Event Suppression structure is read-only by >> -the driver and controls the events sent by the driver >> -to the device (e.g. IO). >> +the driver and controls the available buffer notifications (sent by the >> +driver to the device). > > Here as well. > Nod. >> >> -Each of these Event Suppression structures controls >> -both Descriptor Ring events and structure events, and >> -each includes the following fields: >> +Each of these Event Suppression includes the following fields: > > "Event Suppression" what? Keep "structures"? > Oh that was unintended. >> >> \begin{description} >> \item [Descriptor Ring Change Event Flags] Takes values: >> @@ -352,9 +351,9 @@ matches this value and a descriptor is >> made available/used respectively. >> \end{description} >> >> -After writing out some descriptors, both the device and the driver >> +After writing out some descriptors, the device/driver > > Keep this unchanged? > >> are expected to consult the relevant structure to find out >> -whether an interrupt/notification should be sent. >> +whether a(n) used/available buffer notification should be sent. > > "whether a used respectively an available buffer notification..."? > I wasn't really satisfied with my sentence. Now I see that my initial concern with 'both' (which I tried to avoid) is not valid. I will change it. Thanks for your review! Halil >> >> \subsubsection{Structure Size and Alignment} >> \label{sec:Packed Virtqueues / Structure Size and Alignment} >