[ovs-dev] [PATCH v2] Fix redundant datapath set ethernet action with NSH Decap

Ilya Maximets i.maximets at ovn.org
Wed Jun 16 12:13:11 UTC 2021

On 6/7/21 6:12 PM, Jan Scheurich wrote:
>> -----Original Message-----
>> From: Martin Varghese <martinvarghesenokia at gmail.com>
>> Sent: Monday, 7 June, 2021 16:47
>> To: Ilya Maximets <i.maximets at ovn.org>
>> Cc: dev at openvswitch.org; echaudro at redhat.com; Jan Scheurich
>> <jan.scheurich at ericsson.com>; Martin Varghese
>> <martin.varghese at nokia.com>
>> Subject: Re: [ovs-dev] [PATCH v2] Fix redundant datapath set ethernet action
>> with NSH Decap
>> On Wed, May 19, 2021 at 12:26:40PM +0200, Ilya Maximets wrote:
>>> On 5/19/21 5:26 AM, Martin Varghese wrote:
>>>> On Tue, May 18, 2021 at 10:03:39PM +0200, Ilya Maximets wrote:
>>>>> On 5/17/21 3:45 PM, Martin Varghese wrote:
>>>>>> From: Martin Varghese <martin.varghese at nokia.com>
>>>>>> When a decap action is applied on NSH header encapsulatiing a
>>>>>> ethernet packet a redundant set mac address action is programmed
>>>>>> to the datapath.
>>>>>> Fixes: f839892a206a ("OF support and translation of generic encap
>>>>>> and decap")
>>>>>> Signed-off-by: Martin Varghese <martin.varghese at nokia.com>
>>>>>> Acked-by: Jan Scheurich <jan.scheurich at ericsson.com>
>>>>>> Acked-by: Eelco Chaudron <echaudro at redhat.com>
>>>>>> ---
>>>>>> Changes in v2:
>>>>>>   - Fixed code styling
>>>>>>   - Added Ack from jan.scheurich at ericsson.com
>>>>>>   - Added Ack from echaudro at redhat.com
>>>>> Hi, Martin.
>>>>> For some reason this patch triggers frequent failures of the
>>>>> following unit test:
>>>>> 2314. packet-type-aware.at:619: testing ptap - L3 over patch port
>>>>> ...
>> The test is failing as, during revalidation, NORMAL action is dropping packets.
>> With these changes, the mac address in flow structures get cleared with decap
>> action. Hence the NORMAL action drops the packet assuming a loop (SRC and
>> DST mac address are zero). I assume NORMAL action handling in
>> xlate_push_stats_entry is not adapted for l3 packet. The timing at which
>> revalidator gets triggered explains the sporadicity of the issue. The issue is
>> never seen as the MAC addresses in flow structure were not cleared with decap
>> before.
>> So can we use NORMAL action with a L3 packet ?  Does OVS handle all the L3
>> use cases with Normal action ? If not, shouldn't we not use NORMAL action in
>> this test case
>> Comments?
> Good catch! Normal flow L2 bridging is of course nonsense for the use case of forwarding an L3 packet. I am surprised that the packet was forwarded at all in the first place. That in itself can be considered a bug. Correctly, a Normal flow should drop non-Ethernet packets, I would say.
> To fix the test case I suggest to replace the Normal action in br1 with "output:gre1" in line 700.

OK.  With the test case fix that I applied earlier today, this patch
works fine for me.  So, applied to master.

Best regards, Ilya Maximets.

More information about the dev mailing list