Hi Ben, I see your point. The table lookup is far removed from output. But let's replace write_action with apply_action and see your explanation again. In this latter case the output would be caused by a group, which would be caused by goto_table action that was found by a table_lookup and table_id would be relevant. Compared with write_action, in that case there is an additional action set element in the "caused by"-chain.
Furthermore the table_id=0 can be observed when using write_actions(output:CONTROLLER) as well. Having the following setup: $ ovs-ofctl dump-flows br-test OFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=639.674s, table=0, n_packets=5, n_bytes=440, in_port=1 actions=write_actions(CONTROLLER:65535),goto_table:1 cookie=0x0, duration=690.922s, table=1, n_packets=5, n_bytes=440, actions=CONTROLLER:65535,goto_table:2 cookie=0x0, duration=292.224s, table=2, n_packets=5, n_bytes=440, actions=CONTROLLER:65535,write_actions(CONTROLLER:65535),goto_table:3 cookie=0x0, duration=690.796s, table=3, n_packets=5, n_bytes=440, actions=group:1234 $ ovs-ofctl dump-groups br-test OFPST_GROUP_DESC reply (OF1.3) (xid=0x2): group_id=1234,type=all,bucket=actions=output:10,bucket=actions=CONTROLLER:65535 If a packet is received on port 1, then packet_in messages are triggered by actions=output:CONTROLLER in tables 1, 2 and in group 1234 (with table_id = 1, 2 and 3) and finally a packet_in is triggered by write_action(output:CONTROLLER) in table 2. But this last one has table_id = 0. So, the first packet_in (with table_id = 1) is triggered by an output action found by a table lookup in table 1. The last packet_in (with table_id = 0) was triggered by an output action caused by the action set, which is from an action found by a table lookup in table 2. I don't know how other OpenFlow switches handle these cases. I need to do some research. Best regards, Zoltan -----Original Message----- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Thursday, April 14, 2016 1:16 AM To: Zoltán Balogh Cc: discuss@openvswitch.org Subject: Re: [ovs-discuss] table_id becomes zero in PACKET_IN when using write_action(group) instead of group > The comment says that table_id member is "the ID of the table that was looked > up". > > I investigated the action translator code in ofproto-dpif-xlate.c. I think it > would be easy to store the current table ID in a new member of current > xlate_ctx structure when action translation through the flow-chain is ongoing > and a write_actions(output) or a write_actions(group) action is processed. > So this way, the ID of the last table in the flow-chain that contains > write_actions(output) or write_actions(group) could be stored. That could be > done in xlate_write_actions(). > > Then later, when the current action set is processed and there is an output > action in the set, then this stored table_id could be used as table_id of > current context when translating an output action and output port is > CONTROLLER. This should be performed in xlate_output_action(). > > What do you think? If it's ok, I would create a patch. The table lookup is far removed from the output. The output is caused by a group, which is in turn caused by the action set, which is in turn from an action found by a table lookup. It's not at all obvious to me that the table lookup is relevant. What do other OpenFlow switches do? _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
