On 2 Dec 2024, at 13:18, Ilya Maximets wrote:
> On 12/2/24 13:02, Eelco Chaudron wrote:
>>
>>
>> On 2 Dec 2024, at 12:49, Ilya Maximets wrote:
>>
>>> On 12/2/24 12:43, Eelco Chaudron wrote:
>>>>
>>>>
>>>> On 2 Dec 2024, at 12:34, Ilya Maximets wrote:
>>>>
>>>>> On 11/29/24 15:45, Eelco Chaudron wrote:
>>>
>>> <snip>
>>>
>>>>>>
>>>>>> Hi Ales,
>>>>>>
>>>>>> It took me a bit longer to figure out what was going on, but I found the
>>>>>> issue. Your test case creates three DP flows. The first two flows uses
>>>>>> the dp_hash()/hash() match/action, which is not offloadable, while the
>>>>>> third flow is simple and offloadable.
>>>>>>
>>>>>> What happens next is that the first two flows are processed in the ovs
>>>>>> kernel module. However, as the third recirculated flow is applied in TC,
>>>>>> it still does not exist in the kernel DP. As a result, the packet is
>>>>>> sent for upcall handling. This process repeats for every packet as the
>>>>>> flow keeps being installed in TC.
>>>>>>
>>>>>> - [ovs]
>>>>>> recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(dst=10.0.0.2,frag=no),
>>>>>> packets:9, bytes:882, used:0.125s, actions:hash(l4(0)),recirc(0x3)
>>>>>> - [ovs]
>>>>>> recirc_id(0x3),dp_hash(0xa/0xf),in_port(2),eth(),eth_type(0x0800),ipv4(frag=no),
>>>>>> packets:9, bytes:882, used:0.125s, actions:ct(commit),recirc(0x4)
>>>>>> - [tc ] recirc_id(0x4),in_port(2),eth(),eth_type(0x0800),ipv4(frag=no),
>>>>>> packets:0, bytes:0, used:never, actions:3
>>>>>
>>>>> Hmm, but if the flow is in TC, why it is not dumped back and revalidated?
>>>>> It shouldn't matter if it has any traffic or not.
>>>>
>>>> Not sure I understand your comment. It’s revalidated and removed in the
>>>> end (as no traffic is hitting this rule). But if traffic comes again, we
>>>> install it in TC again, so the same problem repeats.
>>>
>>> The question is: if the flow is in TC, why it is not showing up in
>>> the detrace output? If it's in TC, it means we have the ukey and
>>> it must have been revalidated at least once.
>>
>> Ah, that part :) Yes, that got me puzzled too. But we do not populate the
>> xcache if there has been no traffic for this flow (which makes sense):
>
> No, no. The flow is always revaliadated when it is dumped for the first time,
> regardless of the traffic:
>
> if (!used) {
> /* Always revalidate the first time a flow is dumped. */
> return true;
> }
>
> Or is need_revalidate == false in this case?
Yes, this is the case, as this is only true if there is a reason to revalidate,
i.e. udpif_revalidate() was called.
>> revalidate_ukey()
>>
>> 2475 }
>> 2476 } else if (!push.n_packets || ukey->xcache
>> 2477 || !populate_xcache(udpif, ukey, push.tcp_flags)) {
>> 2478 result = UKEY_KEEP;
>> 2479 }
>>
>> Why it is working, most of the time in my setup, is because an actual
>> revalidation is happening, and then we do populate the cache independently
>> of received packets (through revalidate_ukey__). Same function;
>>
>> 2462 if (need_revalidate) {
>> 2463 if (should_revalidate(udpif, ukey, push.n_packets)) {
>> 2464 if (!ukey->xcache) {
>> 2465 ukey->xcache = xlate_cache_new();
>> 2466 } else {
>> 2467 xlate_cache_clear(ukey->xcache);
>> 2468 }
>> 2469 result = revalidate_ukey__(udpif, ukey, push.tcp_flags,
>> 2470 odp_actions, recircs,
>> ukey->xcache,
>> 2471 del_reason);
>> 2472 } else {
>> 2473 /* Delete, since it is too expensive to revalidate. */
>> 2474 *del_reason = FDR_TOO_EXPENSIVE;
>> 2475 }
>>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
