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
