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

[Parav Pandit <parav@nvidia.com>]

Hi Heng,

> From: Heng Qi <hengqi@linux.alibaba.com>
> Sent: Thursday, June 1, 2023 11:35 PM
> 
> Hi, Parav.
> 
> I also did some work on this feature, and I think it would be very useful if we
> could work on this interface design and VirtIO Spec together!
>
Sure, happy to bring this alive together.
More below.

> > +
> > +## 3.4 Receive virtqueue n-tuple flow steering (RFS)
> 
> I think this abbreviation can be replaced with eg Receive virtqueue n-tuple flow
> director, RFD? or something else?
One hw vendor product name has director in it, so will probably want to stay away picking such TM.

May be we can just say flow filters.
A filter may have an action and a destination.
So it can be generic enough.


> This allows us to distinguish more clearly from (Accelerated) Recieve Flow
> Steering, (A)RFS.
>
The idea was for ARFS and RFS both to reuse the same underlying infra, just the OS hooks are different. (stack vs user ethtool respectively).
 
> ARFS can *automatically* issue RFS rules based on n-tuple rules, and we can
> still issue n-tuple rules *manually*.
> So RFD seems more reasonable than RFS abbreviation, what do you think?:)
> 
"Receive flow filters" is probably more neutral name. :)

> > +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.
> 
> The mask structure can be considered to reuse the same structure as the key
> structure.
Yes, mask will probably have the bit mask definition.

> 
> > +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.
> 
> We may have an additional requirement internally, such as specifying the queue
> id of a certain VF, but we are still aligning this requirement internally, and it may
> be more reasonable to implement the work involving device group based on
> admin vq.
>
The switch side APIs bit more complex.
We were first considering using the flow filters/steering for the guest driver and extend further for switching side.
 
> > +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.
> 
> Considering the capabilities similar to some current tools such as ethtool, if it is
> a simple implementation, the first match principle can be applied.
> 
Yes, this likely needs refinement, I just wanted to get the seed for priority to be afloat when I wrote.
I am thinking of defining the priority at interface level, and driver can choose first match in the programming model based on the use.

> > +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.
> 
> Do we want to support some user-defined fields, so that manufacturers can
> customize the interpretation of some fields.
>
Yes, we can phase out the common case of ipv{4,6} and {udp,tcp} as first phase and more customs field as second phase.
Those use define fields can be useful in custom filters.