On Fri, Jun 2, 2023 at 6:03?AM Parav Pandit <> wrote:
>
> Add virtio net device requirements for receive flow steering.
While at this, I would go with a well defined RX frame processing
pipeline like a modern NIC instead of adding individual features like:
- filter
- hashing
- queue selection
etc.
Thanks
>
> Signed-off-by: Parav Pandit <>
> ---
> 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,
> +
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.
> +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.
> +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.
> +15. The driver and group owner driver should be able to query supported device
> +
limits for the steering entries.
> +
> --
> 2.26.2
>
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO)
TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe:
> Unsubscribe:
> List help:
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
>
