[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [virtio-comment] RE: [PATCH v5 2/7] Introduce admin command set
> From: Jason Wang <jasowang@redhat.com> > Sent: Wednesday, June 22, 2022 9:27 PM > > 1. proposed new command doesn't demand exposing registers in the PCI > > memory mapped area 2. Today AQ is perceived in to be PF, but it doesn't > have to be. For next 10 years spec may evolve to have AQ for some other > purpose on VFs/SFs. > > Such devices scale at much higher magnitude than PFs. > > And exposing memory mapped registers for rare functionality is the last > thing to do in my mind. > > 3. Placements of such features bits in an AQ gives device lot more flexibility > on _how_ to implement them. Some in sw, fw, hw, memory die etc. > > Placement of them in PCI register space reduces these options. > > > > So exposing them something in PCI register space has to have strong > technical reason than just simplicity of access. > > I think I know the advantages of admin virtqueue. But this part looks > suspicious and actually the reverse, > > 1) register based transport have been used for years, it's natural to add > features based on the existing transport and what you suggest here limit the > new features to be carried with those transports > 2) admin virtqueue is heavy weight in use cases like nesting, we need a > simple interface > 3) admin virtqueue is not the universal transport for all cases, we've already > had DMA/CMA based transports (e.g ccw and rproc) > Are you suggesting only feature bits through register-based transport or all commands via register-based transport?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]