On Mon, Feb 07, 2022 at 04:08:41PM +0100, Cornelia Huck wrote: > On Mon, Feb 07 2022, Max Gurtovoy <[email protected]> wrote: > > > On 2/7/2022 1:51 PM, Cornelia Huck wrote: > >> On Mon, Feb 07 2022, "Michael S. Tsirkin" <[email protected]> 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 <[email protected]> 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.
Yes but as long it is transport specific I don't see why not call this out. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
