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: Monday, June 12, 2023 10:57 PM

[..]
> > +4. The match criteria may optionally also include specific packet
> > +data offset,
> 
> Is this the offset of the packet payload (not including the packet header)? If yes,
> what might be the usage scenarios?
> 
Some packet header fields may not be defined initially by us.
For example some protocol FOO type which has some header after UDP header.
And wants to filter and steer to a specific RQ.

A virtio may not have defined such protocol at the beginning. So a generic extension allows to steer packet.
At that point line between header and data is blurry. :)

> > +   length, and matching pattern, which may not be defined in the standard
> RFC.
> > +5. Action includes (a) dropping or (b) forwarding the packet.
> > +6. Destination location is a receive virtqueue index or rss context.
> > +7. The device should process RFS rules before RSS rules, i.e., when there is a
> > +   miss on the RFS rule RSS rule applies.
> > +8. The device should be able to add/remove these rules at a rate of 100K
> > +   rules/sec.
> 
> Why do we need to add this limit for the device please? I think that different
> devices may handle ctrq at different speeds.
>
ARFS rules insertion is fast and tcp streams should be able to converge quicker on the desired cpu.
So rule insertion should be fast enough.
Many of the device can/may be able to do this as some semi-fast path operation unlike CVQ which is typically a device level control operation, often done as slow process.

So driver-device interface to be able to scale up to low latency and high throughput flow insert/delete ops.
It is ok one device may choose to not support such high rate, but interface definition wise I imagine to be on its own dedicated queue.
 
> > +9. If multiple rules are programmed which has overlapping attributes for a
> > +   received packet, the driver to define the location/priority of the rule.
> > +10. The driver should be able to query flow steering table entries
> programmed in
> > +    the device by the flow id.
> 
> Combining points 9 and 10, can I deduce that the attributes of a flow rule
> include identifier (id), position (index of the rule entry) and priority?

Yes, I also think that way.

> According to point 11, the driver needs to provide a unique id, if the location
> and priority are not provided, they should have predefined default values.
>
Yes.
I am not fully sure of it as it brings some uncertainty in behavior.
So having second thought as driver to always provide it.
 
> > +11. The driver should be able to add the entry for attributes (a) match
> > +    criteria, (b) action, (c) destination and (d) assign a unique id of 32 bits.
> > +12. The driver should be able to delete the steering rule entry via a unique
> id.
> > +13. The driver should be able to add and delete the steering rules in out of
> > +    order manner without depending on previous commands.
> > +14. A group member device should be able to query the attributes of the
> flow
> > +    steering that device supports.
> 
> Does a group member driver support insertion rules? The group owner driver
> and a group member driver should have the ability to add/remove rules for
> themselves.
> 
Yes, Group owner adds rule for the self, not on behalf.
Same as group member.
No difference between them as they operate on self device.

In future, a group owner may want to steer the packet towards a group member, like eswitch.

> > +15. The driver and group owner driver should be able to query supported
> device
> > +    limits for the steering entries.
> > +
> 
> Does this include the number of rules supported by the device? Are there other
> limits?

Lets list down if you have some in mind.