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

[Parav Pandit <parav@nvidia.com>]

Add virtio net device requirements for receive flow filters.

Signed-off-by: Parav Pandit <parav@nvidia.com>
---
changelog:
v0->v1:
- fixed comments from Heng Li
- renamed receive flow steering to receive flow filters
- clarified byte offset in match criteria
---
 net-workstream/features-1.4.md | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/net-workstream/features-1.4.md b/net-workstream/features-1.4.md
index a34556c..fbeb1dd 100644
--- a/net-workstream/features-1.4.md
+++ b/net-workstream/features-1.4.md
@@ -9,6 +9,7 @@ together is desired while updating the virtio net interface.
 1. Device counters visible to the driver
 2. Low latency tx and rx virtqueues for PCI transport
 3. Virtqueue notification coalescing re-arming support
+4  Virtqueue receive flow filters (RFF)
 
 # 3. Requirements
 ## 3.1 Device counters
@@ -169,3 +170,35 @@ struct vnet_rx_completion {
    generated notification. 
 2. When the driver enables the notification coalescing reporting, the device
    to notify again if notification coalescing conditions are met.
+
+## 3.4 Virtqueue receive flow filters (RFF)
+1. The driver should be able to define a receive packet match criteria, an
+   action and a destination for a packet. For example, an ipv4 packet with a
+   multicast address to be steered to the receive vq 0. The second example is
+   ipv4, tcp packet matching a specified IP address and tcp port tuple to
+   steered to receive vq 10.
+2. The match criteria should include exact tuple fields well-defined such as mac
+   address, IP addresses, tcp/udp ports, etc.
+3. The match criteria should also include the field mask.
+4. The match criteria may optionally also include specific packet byte offset,
+   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 RFF rules before RSS rules, i.e., when there is a
+   miss on the RFF rule, RSS rule applies if RSS configuration exists.
+8. The device should be able to add/remove these rules at a rate of 100K
+   rules/sec over a dedicated virtqueue who can complete the flow rule commands
+   in out of order manner.
+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 filter table entries programmed in
+    the device by the flow id.
+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 flow filter rule entry via a unique id.
+13. The driver should be able to add and delete the flow filter rules in out of
+    order manner without depending on previous rules.
+14. A group member device should be able to query the attributes of the flow
+    filter rules that device supports.
+15. The driver and group owner driver should be able to query supported device
+    limits for the flow rule entries.
-- 
2.26.2