virtio — archive

[Jason Wang <parav@nvidia.com>]

On Fri, Jun 2, 2023 at 6:03?AM Parav Pandit <parav@nvidia.com> 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 <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, > + 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: virtio-comment-subscribe@lists.oasis-open.org > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org > List help: virtio-comment-help@lists.oasis-open.org > 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/ >