Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() after packet_type changed

ch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh > Sent: Monday, December 11, 2017 4:39 PM > To: Jan Scheurich <jan.scheur...@ericsson.com>; d...@openvswitch.org; Ben > Pfaff <b...@ovn.org> > Subject: Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() aft

Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() after packet_type changed

Hi, I've been working on the solution proposed by Jan. I faced a new issue with patch ports. Let's have a config like in unit test 1025: "1025: ofproto-dpif - balance-tcp bonding, different recirc flow " +-+ | br-int| p5 (OF 5) | o--<---

Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() after packet_type changed

Hi Zoltan, Please find answers below. Regards, Jan > -Original Message- > From: Zoltán Balogh > Sent: Friday, 08 December, 2017 12:56 > To: Jan Scheurich ; d...@openvswitch.org > Cc: Ben Pfaff > Subject: RE: [PATCH] tunnel: fix tnl_find() after

Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() after packet_type changed

At first glance I would try to skip or enhance the port and bridge lookup in upcall_receive() or xlate_lookup() if flow->recirc_id != 0. The code in xlate_actions() actually already today restores bridge and flow.in_port from the thawed frozen_state. We need to make sure that prior to reaching

Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() after packet_type changed

Hello Jan, Thank you for the review. The recirc_id_node, and thus the frozen_state with the the ofproto_uuid can be retrieved from recirc ID via recirc_id_node_find(). So I think, it would be feasible to get the ofproto from the recirc ID without calling tnl_find(). In addition we would need

Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() after packet_type changed

Hi Zoltan, My feeling here is that it is conceptually wrong to do another tunnel lookup if the packet is recirculated after it has already been de-tunneled. You are trying to fix the symptoms and I am not sure that the more liberal check on packet type won't lead to incorrect proper tunnel

[ovs-dev] [PATCH] tunnel: fix tnl_find() after packet_type changed

During xlate, it can happen that tnl_find() is invoked when flow packet_type has been already changed. For instance, pop_mpls and resubmit actions should be applied to the packet in overlay bridge after packet was received on a legacy_l3 tunnel port. In this case, packet is recirculated after