Hi Xuan, > From: Xuan Zhuo <xuanz...@linux.alibaba.com> > Sent: Sunday, July 2, 2023 11:22 PM
> I try to describe the requirement as a common requirement. > > @Parav do you think this is a requirement in your devices? > > The core point here is that our virtio-net device is created by customers on > the > management platform. It is not a pure virtio-net device, but also includes > many > other features, such as bandwidth, such as VPC information, etc. When these devices are on PCI transport, and if they are PF. PCI VPD has well defined serial number, and few more fields. This helps to cross identify the device between compute side where virtio device is used and other management side, who inserted this virtio PCI device in the compute. > These are not > within the scope of virtio, we cannot configure these information based on the > admin queue after creating the vf. But we can bind the device created by the > user to vf, which completes the binding of many manufacturer features to vf. > > In addition to this scenario, in the case of live migration, we can migrate a > vm > from one host to another host. During this process, the virtio-net devce is > also > migrated from the dpu of one host to the dpu of another host . At this time, > the > purpose of creating a vf is to insert the migrated virtio-net into the host. > It is > impossible for us to create a vf to get a brand new device. So also bind. > For the VF in this flow looks like below. a. device id assignment is initiated by the compute side AQ to a VF (on destination) b. management system received the command and queried some central place to get attributed (qos etc), that you described. Here somehow the src side already had access to the management system in first place for the VF backend configuration. And I believe same access is/should be possible on the destination side too. So that same parameter can be configured as out of band command. In fact for virtio device migration, a migrating sw may even need to inspect and figure out which is the best system to migrate to in the backend. So out of band access is present and needed that can rely on the VF number to provision these things without explicit bind command. So bind command is optional command that can help to do the work that is already done today out of band. And if bind on specific system is identified, it is probably better to do this out of band. Your key point is " virtio-net device is created by customers on the management platform". If they are based on the VF, it can be identified uniquely by the VF number without explicit bind command. For PF and VF I responded few other ideas before at [1], you probably missed it. [1] https://lore.kernel.org/virtio-comment/20230628112107-mutt-send-email-...@kernel.org/T/#m99518f22871a223c4dd014bb77e712b3befd9793 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
