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

[Heng Qi <hengqi@linux.alibaba.com>]

å 2023/6/14 äå11:48, Parav Pandit åé:
> > 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.

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.