virtio — archive

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

From: Heng Qi <[email protected]>
To: [email protected]
Date: Wed, 14 Jun 2023 03:53:00 -0000

? 2023/6/14 ??11:48, Parav Pandit ??: >> 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. Ok, I see. I misunderstood the "preferred way" before :) > > 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. >