More on my day's debugging: my previous comment was a bit premature, and a
bit confusing. To clarify:
- dpif flows are not being deleted in time when the basic.OutputExact test
runs on our most recent code
- dpif flows are being deleted in time on last year's code (based on my
previous upgrade from tip of master)
- the reason they are being deleted at all is based on the return from
revalidate_ukey(), which works in last year's code
- the latest code also appears to be making the decision to delete the flow
based on revalidate_ukey()
- so, I need to keep looking and stop talking to the list!
Tony
On Fri, Jun 5, 2015 at 5:50 PM, Tony van der Peet <tony.vanderp...@gmail.com
> wrote:
> Alex and group
>
> This is a repeat of my earlier reply, sent also to the list (sorry about
> dropping the list). Plus some information about my day's debugging.
>
> Tony
>
> On Thu, Jun 4, 2015 at 6:05 PM, Alex Wang <al...@nicira.com> wrote:
>
>> Hey,
>>
>> Few questions,
>>
>> 1. how do you change the flow to output to port 2? using
>> ovs-ofctl mod-flows? Could you show the exact commands?
>>
>
> I'm running an oftest test case, in the v1.3 tests, called
> basic.OutputExact. The code is:
>
> class OutputExact(base_tests.SimpleDataPlane):
> """
> Test output function for an exact-match flow
>
> For each port A, adds a flow directing matching packets to that port.
> Then, for all other ports B != A, verifies that sending a matching
> packet
> to B results in an output to A.
> """
> def runTest(self):
> ports = sorted(config["port_map"].keys())
>
> delete_all_flows(self.controller)
>
> parsed_pkt = simple_tcp_packet()
> pkt = str(parsed_pkt)
> match = packet_to_flow_match(self, parsed_pkt)
>
> for out_port in ports:
> request = ofp.message.flow_add(
> table_id=test_param_get("table", 0),
> cookie=42,
> match=match,
> instructions=[
> ofp.instruction.apply_actions(
> actions=[
> ofp.action.output(
> port=out_port,
> max_len=ofp.OFPCML_NO_BUFFER)])],
> buffer_id=ofp.OFP_NO_BUFFER,
> priority=1000)
>
> logging.info("Inserting flow sending matching packets to port
> %d", out_port)
> self.controller.message_send(request)
> do_barrier(self.controller)
>
> for in_port in ports:
> if in_port == out_port:
> continue
> logging.info("OutputExact test, ports %d to %d", in_port,
> out_port)
> self.dataplane.send(in_port, pkt)
> verify_packets(self, pkt, [out_port])
>
>
>> 2. There was a commit (b2a4692 ofproto: Increase default datapath
>> max_idle time.) that increased the max_idle time of dpif flows. That may
>> be related.
>>
>
> Not related, our code had already increased the timeout to 6s.
>
> My day's debugging: I am in a version of our build based on my previous
> upgrade last year, and it passes the test. I'm in revalidate() and seeing
> that flows are being deleted due to the return from revalidate_ukey(),
> which sort of makes sense to me. The fact that udpif->need_revalidate is no
> longer being set seems a bit suspicious to me. I will continue to work on
> this and will update next week (since it's my Friday!).
>
> Tony
>
>
>> Thanks,
>> Alex Wang,
>>
>> On Wed, Jun 3, 2015 at 10:37 PM, Tony van der Peet <
>> tony.vanderp...@gmail.com> wrote:
>>
>>> I use OpenVSwitch and occasionally upgrade from the tip of master. My
>>> previous upgrade was in Sep/2014, and I have just upgraded to last Friday's
>>> tip. A number of previously running test cases (using oftest) now fail for
>>> me, and I am investigating.
>>>
>>> The v1.3 test basic.OutputExact creates a flow outputting to port 1,
>>> then sends packets in ports 2, 3 and 4. The flow is then changed to output
>>> to port 2 instead. Since everything else about the flow is the same, this
>>> actually represents a change in the same flow (in my opinion) and therefore
>>> the dpif flows created when packets were received should now be invalid.
>>> However, when a packet is sent on port 3, instead of being output to port
>>> 2, it is output to port 1, causing the test to fail.
>>>
>>> I think what's happening is that the dpif flows are not being deleted
>>> when the flow changes. I am almost certain that this is not how the code
>>> used to behave. I have also tweaked the test to explicitly remove the flow
>>> before changing the output port, and this test passes.
>>>
>>> The questions I have are: Can anyone point me to the code change that
>>> might have introduced this behaviour? Is it a deliberate change or a
>>> by-product? While I could happily proceed by changing our regression test,
>>> I would rather see if this behaviour can be altered to behave the way it
>>> used to, which seems to me to be more conformant to the specification.
>>>
>>> Any advice gratefully accepted.
>>>
>>> Tony
>>>
>>> _______________________________________________
>>> discuss mailing list
>>> discuss@openvswitch.org
>>> http://openvswitch.org/mailman/listinfo/discuss
>>>
>>>
>>
>
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
