OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[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]