[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v3 1/4] Add virtio Admin virtqueue
On Mon, Feb 07 2022, Max Gurtovoy <mgurtovoy@nvidia.com> wrote: > On 2/7/2022 1:51 PM, Cornelia Huck wrote: >> On Mon, Feb 07 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote: >> >>> On Mon, Feb 07, 2022 at 12:14:33PM +0200, Max Gurtovoy wrote: >>>> On 2/3/2022 3:09 PM, Cornelia Huck wrote: >>>>> On Thu, Feb 03 2022, Max Gurtovoy <mgurtovoy@nvidia.com> wrote: >>>>>> +commands to manipulate various features of the device and/or to manipulate >>>>>> +various features, if possible, of another device within the same group (e.g. PCI VFs >>>>> Maybe add >>>>> >>>>> "Which devices are actually considered a group is transport specific." >>>>> >>>>> ? >>>> Not sure we want to restrict ourselves for that. >>> do restrict this please, if we want to extend the scope we can >>> always do that down the road. >> I'm also not sure how grouping can _not_ be transport specific... the >> PF/VF example is obviously a pci thing; for ccw, in a non-virtio >> context, there's sometimes the concept of some subchannels/devices being >> grouped together with no clear hierarchy, and for mmio, I don't really >> have an idea how "grouping" might work there. > > Yes today it's transport specific. > > But if one day there will be a definition for virtio fabric (over > TCP/RDMA) it might not be true. I don't think that is contadictory; we can simply extend the meaning of what "grouping" means when needed.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]