I agree that with apply_actions it makes sense to supply the table_id of the flow that output to the group. I don't object to fixing that--do you want to supply a patch?
On Thu, Apr 14, 2016 at 02:29:24PM +0000, Zoltán Balogh wrote: > > 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
