[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH v5 08/10] vhost-user: remove the extra PCI capabilities
On 23/7/20 9:29 Ï.Î., Stefan Hajnoczi wrote:
On Fri, Jul 17, 2020 at 06:03:57PM +0300, Nikos Dragazis wrote:On 17/7/20 12:48 Î.Î., Stefan Hajnoczi wrote:On Mon, May 18, 2020 at 11:37:19PM +0300, Nikos Dragazis wrote:-Additional resources are configured on the virtio PCI transport by the following \field{struct virtio_pci_cap.cfg_type} values: +\subsubsection{Doorbell layout}\label{sec:Device Types / Vhost-user Device Backend / Additional Device Resources / Doorbell layout} -\begin{lstlisting} -#define VIRTIO_PCI_CAP_DOORBELL_CFG 6 -#define VIRTIO_PCI_CAP_NOTIFICATION_CFG 7 -#define VIRTIO_PCI_CAP_SHARED_MEMORY_CFG 8 -\end{lstlisting} +The device MUST reserve 2N+1 virtqueue indices that can be used by the driver to +send doorbell notifications. The driver can use these indices to send doorbell +notifications in the same way that it sends available buffer notifications +\ref{sec:Basic Facilities of a Virtio Device / Notifications} for a virtqueue.Notifications and doorbells should be first-class VIRTIO device model concepts, like Shared Memory resources. It should not be necessary to reserve dummy virtqueues (a hack for getting MSI-X vectors and doorbell registers).Well, it's not exactly equivalent to the shared memory resource because, in case of doorbells and notifications, the functionality is already there. But I see your point. It is a design issue. We could definitely standardize the doorbell and notification resources, but I don't see why this solution is preferable. Do you have something in mind?Yes, there are advantages to defining doorbells and notifications as separate concepts: * Doorbells and notifications may be implemented differently from virtqueue notifications on some the transports. * Virtqueues may consume more resources on some transports. * Existing drivers may have issues distinguishing between normal virtqueues and dummy virtqueues. Overall I think using dummy virtqueues is a hacky approach. It's something that would be necessary if we couldn't extend the core VIRTIO device model. Since we do have the opportunity of extending the core VIRTIO device model cleanly I think doing so will avoid headaches later. Stefan
OK. Let's standardize them. I will send a separate patch for this. I can't think of all the details right now, so, I'll come back if anything troubles me. Nikos
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]