RE: [virtio] [PATCH requirements 5/7] net-features: Add n-tuple receive flow steering requirements

[Parav Pandit <parav@nvidia.com>]

> From: Heng Qi <hengqi@linux.alibaba.com>
> 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.