Hi Ben,
I found only the definition of ofp_packet_in structure in chapter A.4.1 that
mentions table_id.
/* Packet received on port (datapath -> controller). */
struct ofp_packet_in {
struct ofp_header header;
uint32_t buffer_id; /* ID assigned by datapath. */
uint16_t total_len; /* Full length of frame. */
uint8_t reason; /* Reason packet is being sent (one of OFPR_*) */
uint8_t table_id; /* ID of the table that was looked up */
uint64_t cookie; /* Cookie of the flow entry that was looked up. */
struct ofp_match match; /* Packet metadata. Variable size. */
/* Followed by:
* - Exactly 2 all-zero padding bytes, then
* - An Ethernet frame whose length is inferred from header.length.
* The padding bytes preceding the Ethernet frame ensure that the IP
* header (if any) following the Ethernet header is 32-bit aligned.
*/
//uint8_t pad[2]; /* Align to 64 bit + 16 bit */
//uint8_t data[0]; /* Ethernet frame */
};
OFP_ASSERT(sizeof(struct ofp_packet_in) == 32);
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.
Best regards,
Zoltan
-----Original Message-----
From: Ben Pfaff [mailto:[email protected]]
Sent: Monday, April 11, 2016 5:25 PM
To: Zoltán Balogh
Cc: [email protected]
Subject: Re: [ovs-discuss] table_id becomes zero in PACKET_IN when using
write_action(group) instead of group
On Mon, Apr 11, 2016 at 02:02:00PM +0000, Zoltán Balogh wrote:
> Hi,
>
> In ovs 2.5.0 I observed the following.
> I added a group and flows with these commands:
>
> ovs-ofctl -OOpenFlow13 add-group br1
> group_id=100,type=indirect,bucket=actions=output:CONTROLLER
> ovs-ofctl -OOpenFlow13 add-flow br1
> table=0,priority=100,in_port=110,arp,arp_op=2,actions=write_metadata:1
> 11,goto_table:80 ovs-ofctl -OOpenFlow13 add-flow br1
> table=80,metadata=111,actions=group:100
>
> In this case the PACKET_IN message sent to the controller indicates
> table_id=80.
>
> If I use write_action (instead of default apply_action) in the last flow like
> this:
>
> ovs-ofctl -OOpenFlow13 add-group br1
> group_id=100,type=indirect,bucket=actions=output:CONTROLLER
> ovs-ofctl -OOpenFlow13 add-flow br1
> table=0,priority=100,in_port=110,arp,arp_op=2,actions=write_metadata:1
> 11,goto_table:80 ovs-ofctl -OOpenFlow13 add-flow br1
> table=80,metadata=111,actions=write_actions\(group:100\)
>
> then the PACKET_IN indicates table_id=0.
>
> Does this behavior correspond with OpenFlow1.3? I found only this: "For the
> Write-Actions instruction, the actions field is treated as a set and the
> actions are merged into the current action set"
The effects of a write_actions instructions are pretty far removed from the
table that wrote it. I think it's reasonable to report an arbitrary table_id
there (probably 255 would be better than 0, but the spec doesn't say).
I don't know of a citation in the specification for this. If you find one, let
us know.
If you use a later version of OpenFlow then you'll get a more specific "reason"
of OFPR_GROUP or OFPR_ACTION_SET (not sure which), which might help.
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
