virtio — archive

[PATCH requirements 0/7] virtio net new features requirements

From: Parav Pandit <[email protected]>
To: [email protected]
Date: Wed, 14 Jun 2023 03:48:00 -0000

> From: Heng Qi <[email protected]> > Sent: Tuesday, June 13, 2023 11:43 PM > > If it’s a "flowvq" dedicated queue device both the requirements are > addressed. > > Device can choose to implement in its preferred way. > > I think this is a migration issue: > Devices A and B each offser the VIRTIO_NET_F_RECEIVE_FLOW_FILTER (this is a > temporary name) feature. > And device A implements flowvq, device B does not implement flowvq, they are > both using receive flow filters but ARFS is disabled. > The migration should fail at this time. Does this meet user expectations? > If F_RECEIVE_FLOW_FILTER is offered, it means a device supports flowvq on src and dst. So migration wont fail. It is no different than any other net _F feature. For example notification coalescing or _MQ or _RSS. What I meant in above "preferred way" is, device can choose to operate flow table entries as 5 flow/sec. Or it can choose to do 100K flows/sec. The basic requirement is that flow rule entries should be a low latency interface. > Or do we warn in the spec that using flow vq might cause the migration issue? > It should not cause migration once the device features and associated attributes can be queries by the group owner.