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

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

å 2023/6/2 äå6:03, Parav Pandit åé:
> Add virtio net device requirements for receive flow steering.
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
>   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 fc36f31..41242b4 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. Receive virtqueue n-tuple steering
>   
>   # 3. Requirements
>   ## 3.1 Device counters
> @@ -151,3 +152,35 @@ struct vnet_rx_completion {
>      coalescing after processing the packets per VQ. This ensures that when
>      networking stack decides to poll, no new notifications are generated when
>      per VQ notification coalescing is used.
> +
> +## 3.4 Receive virtqueue n-tuple flow steering (RFS)
> +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 data offset,

Is this the offset of the packet payload (not including the packet 
header)? If yes, what might be the usage scenarios?

> +   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.

> +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?
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.

> +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.

> +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?

Thanks!