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

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Tuesday, June 6, 2023 10:48 PM
> 
> 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
>

Can you explain this from requirements point of view?
Individual features are something that already exists such as queue and hashing.

We are inserting filtering to this pipe.
Do you mean to define the order in the spec? if so, yes, very lightly I described the relation of filtering with RSS.

If more, please explain.

 
> 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/
> >