Re: Question about pattern types for rte_flow RSS rule

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

On 8/1/22 16:27, lihuisong (C) wrote:
> 
> 在 2022/8/1 19:53, Andrew Rybchenko 写道:
>> On 8/1/22 06:39, lihuisong (C) wrote:
>>>
>>> 在 2022/7/31 17:40, Andrew Rybchenko 写道:
>>>> Hi, Huisong!
>>>>
>>>> On 7/29/22 05:30, lihuisong (C) wrote:
>>>>> Hi Ori, and all,
>>>>>
>>>>> For RSS flow rule, pattern item types and RSS types in action
>>>>> are an inclusive relationship, and RSS types contain pattern item
>>>>> types. 
>>>>
>>>> I disagree with the statement. We can redirect various packets,
>>>> but apply RSS on subset only. Everything else goes to the first
>>>> queue (first entry in the redirection table in fact).
>>> Sorry, the statement above is inaccurate.
>>> I mean, pattern item type and RSS types in action are the same for
>>> creating specified types RSS rule, and this configuration is duplicate
>>> in this case(in <1> command, I think). Use one of them can specify
>>> which packet type flow performs action(like <1> or <2> command).
>>
>> No, I still disagree. Pattern is about filtering. It defines on which
>> packets flow rule actions are applied. RSS types choose packet header
>> fields (if applicable) to calculate hash. I.e. RSS types are no about
>> filtering.
>>
>>>
>>> Create a RSS rule that redirect ipv4-tcp flow to queues 1 and 2:
>>> <1> flow create 0 ingress pattern eth / ipv4 / tcp / end actions rss 
>>> types ipv4-tcp end queues 1 2 end / end
>>
>> Yes, this one will redirect IPv4 TCP packets only.
>>
>>> <2> flow create 0 ingress pattern end actions rss types ipv4-tcp end 
>>> queues 1 2 end / end
>>
>> The rule will redirect all packets to queues 1 and 2. Some packets will
>> always go to queue 1, e.g. ARP packets.
>>
> In this case, only nonfrag ipv4 TCP packet flow calculate RSS hash and may
> distribute to queue 1 and 2 in hardware, and other packets will always go
> to queue 1, right?

Yes.

>>> <3> flow create 0 ingress pattern eth / ipv4 / tcp / end actions rss 
>>> end queues 1 2 end / end
>>
>> This one will redirect IPv4 TCP and will use RSS hash function specified
>> in dev_conf on device configuration or default RSS hash function chosen
>> by corresponding driver.
>>
>>>
>>> What do you think about it, @Andrew and @Ori?
>>>>
>>>>> Is it necessary to set pattern item types when specify RSS
>>>>> types to create a rule? 
>>>>
>>>> No, it is not strictly required. It depends on what you want.
>>>>
>>>>> How should the user set and how should the
>>>>> driver do?
>>>>
>>>> Pattern and action are not strictly related in the case of RSS.
>>>> Pattern defines on which packets the rule is applied.
>>>> Action defines what the rule does. If hash function is not
>>>> applicable to a packet, e.g. ARP packet and ipv4-tcp hash function,
>>>> the hash is 0 and goes via redirection table entry 0.
>>> I know this rule. Ori has already explained the usage of RSS rule in 
>>> rte_flow API,
>>> but I still have a confusion momentioned above.
>>>>
>>>> Andrew.
>>>>
>>>>>
>>>>> Looking forward to your reply.
>>>>>
>>>>> Regards,
>>>>> Huisong
>>>>>
>>>>> 在 2022/7/13 9:34, lihuisong (C) 写道:
>>>>>> Hi all,
>>>>>>
>>>>>> Can someone open my confusion?
>>>>>> I'm looking forward to your reply.
>>>>>>
>>>>>> Thanks,
>>>>>> Huisong.
>>>>>>
>>>>>> 在 2022/7/7 11:50, lihuisong (C) 写道:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> From following testpmd command:
>>>>>>> 'flow create 0 ingress pattern eth / ipv4 / tcp / end actions rss 
>>>>>>> types ipv4-tcp l3-src-only end queues end / end'
>>>>>>> and
>>>>>>> "flow create 0 ingress pattern end actions rss types ipv4-tcp 
>>>>>>> l3-src-only end queues end / end"
>>>>>>>
>>>>>>> I have some confusions about rte_flow RSS rule:
>>>>>>> 1> Do pattern item types need to set when configure rte_flow RSS 
>>>>>>> rule?
>>>>>>> 2> Does the driver need to check and process the pattern? (After 
>>>>>>> all, the RSS types in actions alreadly contain all RSS offload 
>>>>>>> types.)
>>>>>>>
>>>>>>> Have someone explains it?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Huisong
>>>>>>>
>>>>>>> .
>>>>>> .
>>>>
>>>> .
>>
>> .