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

[Parav Pandit <parav@nvidia.com>]

> From: Heng Qi <hengqi@linux.alibaba.com>
> Sent: Friday, August 4, 2023 12:47 PM

> Yes, but a small update:
> If flowvq is created, RFF must be done only on flowvq by the driver.
> If flowvq is supported, but not created, cvq can be used.
> If flowvq is not supported, cvq is used.
>
Looks fine, I want to think little more on the last point to make sure we are not missing something.
Will respond by Monday on it.
[..]

> Oh, I got it, I think we should let people see more details in the next version.:)
> 
> > For any new/undefined protocol, if user wants to say, In a packet at
> > byte offset A, if you find pattern == 0x800, drop the packet.
> > In a packet at byte offset B, if you find pattern == 0x8100, forward to rq 10.
> >
> > I didn't consider multiple matching patterns for now, though it is very useful.
> > I am inclined to keep the option of _any_match to take up later, for now to do
> only well defined match?
> > WDYT?
> 
> I think it's ok, but we don't seem to need the length here. But in any case, I
> don't think it's that important to have or not ^^
>
Length will be needed to indicate how many bytes to match to.
Lets do this rule incrementally after we get the base line done for known RFC defined fields.

> > Lets keep rss context in future work as its orthogonal to it.
> > Yes, your help for rss context will be good.
> > Lets first finish RFF as its bit in the advance stage.
> 
> Yes! But I worry that a spec that references a concept that doesn't exist in the
> existing spec may be blocked, so if you have no objections, I will push this work
> forward in the near future to help RFF possible blocking.

I was probably not clear enough, I propose that lets remove the RSS context for now in the RFF.
Once RSS context is done, at that point in future to enhance RFF.