[PATCH v7] ethdev: add special flags when creating async transfer table

[Andrew Rybchenko]

On 2/2/23 14:29, Thomas Monjalon wrote:
> 02/02/2023 10:21, Andrew Rybchenko:
>> On 2/1/23 16:48, Thomas Monjalon wrote:
>>> 01/02/2023 12:38, Andrew Rybchenko:
>>>> On 2/1/23 14:18, Thomas Monjalon wrote:
>>>>> 01/02/2023 12:10, Andrew Rybchenko:
>>>>>> On 2/1/23 13:58, Thomas Monjalon wrote:
>>>>>>> 01/02/2023 11:17, Andrew Rybchenko:
>>>>>>>> On 1/18/23 19:18, Thomas Monjalon wrote:
>>>>>>>>> 18/01/2023 08:28, Andrew Rybchenko:
>>>>>>>>>> On 11/14/22 14:59, Rongwei Liu wrote:
>>>>>>>>>>> In case flow rules match only one kind of traffic in a flow table,
>>>>>>>>>>> then optimization can be done via allocation of this table.
>>>>>>>>>>> Such optimization is possible only if the application gives a hint
>>>>>>>>>>> about its usage of the table during initial configuration.
>>>>>>>>>>>
>>>>>>>>>>> The transfer domain rules may process traffic from wire or vport,
>>>>>>>>>>> which may correspond to two kinds of underlayer resources.
>>>>>>>>>>> That's why the first two hints introduced in this patch are about
>>>>>>>>>>> wire and vport traffic specialization.
>>>>>>>>>>> Wire means traffic arrives from the uplink port while vport means
>>>>>>>>>>> traffic initiated from VF/SF.
>>>>>>>>>>>
>>>>>>>>>>> There are two possible approaches for providing the hints.
>>>>>>>>>>> Using IPv4 as an example:
>>>>>>>>>>> 1. Use pattern item in both template table and flow rules.
>>>>>>>>>>>
>>>>>>>>>>>          pattern_template: pattern ANY_VPORT / eth / ipv4 is 1.1.1.1 / end
>>>>>>>>>>>          async flow create: pattern ANY_VPORT / eth / ipv4 is 1.1.1.2 / end
>>>>>>>>>>>
>>>>>>>>>>>          "ANY_VPORT" needs to be present in each flow rule even if it's
>>>>>>>>>>>          just a hint. No value to match because matching is already done by
>>>>>>>>>>>          IPv4 item.
>>>>>>>>>>>
>>>>>>>>>>> 2. Add special flags into table_attr.
>>>>>>>>>>>
>>>>>>>>>>>          template_table 0 create table_id 0 group 1 transfer vport_orig
>>>>>>>>>>>
>>>>>>>>>>> Approach 1 needs to specify the pattern in each flow rule which wastes
>>>>>>>>>>> memory and is not user friendly.
>>>>>>>>>>> This patch takes the 2nd approach and introduces one new member
>>>>>>>>>>> "specialize" into rte_flow_table_attr to indicate possible flow table
>>>>>>>>>>> optimization.
>>>>>>>>>>
>>>>>>>>>> The above description is misleading. It alternates options (1)
>>>>>>>>>> and (2), but in fact (2) requires (1) as well.
>>>>>>>>>
>>>>>>>>> Yes the above description may be misleading
>>>>>>>>> and it seems you are misleaded :)
>>>>>>>>
>>>>>>>> It is not my intention. If it is only my problem, I'm OK to
>>>>>>>> step back.
>>>>>>>
>>>>>>> It's OK to explain and check everything is OK, no worries.
>>>>>>> Thanks for reviewing.
>>>>>>>
>>>>>>>>> I will explain below why the option (2) doesn't require (1).
>>>>>>>>> I think we should apply the same example to both cases to make it clear:
>>>>>>>>>
>>>>>>>>> 1. Use pattern item in both template table and flow rules:
>>>>>>>>>
>>>>>>>>>         template table 3 = transfer pattern ANY_VPORT / eth / ipv4 src is 255.255.255.255 / end
>>>>>>>>>         flow rule = template_table 3 pattern ANY_VPORT / eth / ipv4 src is 1.1.1.1 / end
>>>>>>>>>
>>>>>>>>>         The pattern template 3 will be used only to match flows coming from vports.
>>>>>>>>>         ANY_VPORT needs to be present in each flow rule.
>>>>>>>>
>>>>>>>> It looks like I lost something here. Why do we need to specify
>>>>>>>> it in each flow rule if the matching is already fixed in
>>>>>>>> template table?
>>>>>>>
>>>>>>> I think that's how template tables are designed.
>>>>>>> Ori, please could you point us to the relevant documentation?
>>>>>>>
>>>>>>>>>         ANY_VPORT matching is redundant with IP src 1.1.1.1 because
>>>>>>>>>         the user knows 1.1.1.1 is the IP of a vport.
>>>>>>>>
>>>>>>>> What should happen if a packet with src IP 1.1.1.1 comes from
>>>>>>>> the wire? Almost anything could come from network.
>>>>>>>
>>>>>>> It a packet comes from a wired port AND
>>>>>>> the PMD did an optimization based on this hint,
>>>>>>> then the packet could be not matched.
>>>>>>
>>>>>> So, the hint changes matching results and therefore becomes
>>>>>> a strange (extra) matching criteria under specific
>>>>>> circumstance. It sounds bad.
>>>>>
>>>>> In this case, the user made a wrong assumption.
>>>>> If the user does not do a mistake, the behavior should be the same
>>>>> whether the hint is used or ignored.
>>>>>
>>>>>> So, good application must use
>>>>>> real (always) matching criteria when composing flow rules.
>>>>>
>>>>> Of course, nothing replaces matching criteria.
>>>>>
>>>>>> So, RTE flow API should provide a way to write a good
>>>>>> application without extra pain.
>>>>>> That's why I'm saying that (2) requires (1) anyway.
>>>>>
>>>>> I don't follow this sentence.
>>>>> If you mean with hint, flow matching is still required, then yes,
>>>>> this is what I emphasized in my rewrite of the case (2) below.
>>>>>
>>>>>> It does not say that hint is not required at all.
>>>>>> It is still useful for resources usage optimization if
>>>>>> application knows how it is going to use particular table.
>>>>>
>>>>> Yes, that's an optional optimization.
>>>>> It should not change the rules,
>>>>> and it should not change the functional behavior
>>>>> if the user does not do mistakes.
>>>>
>>>> So, we basically agree on the topic, but my goal here is a bit
>>>> bigger. Make it easier for a user to avoid mistakes. May be it
>>>> is stupid goal :) and all efforts are vain.
>>>> If we have a match item with similar functionality it would be
>>>> easy to just put it into a pattern. Otherwise, it could be
>>>> complicated, have high chances to be skipped and rely on
>>>> implicit matching criteria imposed by the hint on the HW
>>>> which takes it into account.
>>>
>>> We may highlight in the doc that the functional behaviour must not rely
>>> on the hints. It is only optional optimization and effects may vary
>>> with differents driver.
>>> What do you think? I don't know what else to do about user mistakes :)
>>
>> As I said - add corresponding pattern items.
> 
> I think I get it now.
> You suggest to have pattern items for VPORT and PHY_PORT,
> so the user won't be tempted to use hint for such matching?
> We used to have RTE_FLOW_ITEM_TYPE_PHY_PORT, we could think about it.

Naming is bad since we had PHY_PORT before, but you get the
idea right.

> 
>> Anyway, hint itself is OK and makes sense. Hopefully
>> documentation highlights that pattern match is required.
> 
> Yes we did an effort to highlight what are hints in the last version.
> 
>> If so,
>>
>> Acked-by: Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>
> 
> 
>