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

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

在 2023/6/13 下午12:16, Parav Pandit 写道:
>
>> From: Heng Qi <hengqi@linux.alibaba.com>
>> Sent: Monday, June 12, 2023 10:57 PM
> [..]
>>> +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?
>>
> Some packet header fields may not be defined initially by us.
> For example some protocol FOO type which has some header after UDP header.
> And wants to filter and steer to a specific RQ.

Ok, I got it.

>
> A virtio may not have defined such protocol at the beginning. So a generic extension allows to steer packet.
> At that point line between header and data is blurry. :)

Then I think it's just an *offset* from the start of the packet so we 
can use this capability for the packet header as well.

>
>>> +   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.
>>
> ARFS rules insertion is fast and tcp streams should be able to converge quicker on the desired cpu.
> So rule insertion should be fast enough.
> Many of the device can/may be able to do this as some semi-fast path operation unlike CVQ which is typically a device level control operation, often done as slow process.

We need to consider ARFS for receive flow filters, but receive flow 
filters are more infrastructure,
do we need to offer a sub-feature to distinguish whether a device 
supports this dedicated queue or not.
This becomes easier for users who only use receive flow filters without 
ARFS enabled.
At this point, ARFS and receive flow filters become orthogonal.

>
> So driver-device interface to be able to scale up to low latency and high throughput flow insert/delete ops.

Ok.

> It is ok one device may choose to not support such high rate, but interface definition wise I imagine to be on its own dedicated queue.
>   
>>> +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?
> Yes, I also think that way.
>
>> 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.
>>
> Yes.
> I am not fully sure of it as it brings some uncertainty in behavior.
> So having second thought as driver to always provide it.

Yes, and this point is specific, then we can continue to confirm it in 
the future spec version.

>   
>>> +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.
>>
> Yes, Group owner adds rule for the self, not on behalf.
> Same as group member.
> No difference between them as they operate on self device.

Ok.

>
> In future, a group owner may want to steer the packet towards a group member, like eswitch.

Yes.
And what I want to say is that our cloud architecture is similar to 
two-layer virtualization, but we only have one layer of eswitch,
so we need VF id to let eswitch provide simple flow steering for the 
second layer of virtualization, and do not need complicated eswitch.
This is the purpose of carrying VF id, but now we can not consider this 
(VF id) in the feature of receive flow filters, so as not to hinder the 
progress of this feature.

>
>>> +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?
> Lets list down if you have some in mind.
Not yet.

Thanks!


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/