[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] Problem with designing the feature of muitiple-action
From:       blp () nicira ! com (Ben Pfaff)
Date:       2012-07-23 17:02:16
Message-ID: 20120723170216.GL6013 () nicira ! com
[Download RAW message or body]

On Mon, Jul 23, 2012 at 04:29:26PM +0800, chenzh wrote:
> In function do_execute_actions(action.c line 370)
> /* Execute a list of actions against 'skb'. */
> static int do_execute_actions(struct datapath *dp, struct sk_buff *skb,
> 			const struct nlattr *attr, int len, bool keep_skb)
> It seems this function are doing the following job:
> 1. Directly modify the original packet
> 2. Output this packet
> 3. Loop to the second action
> But, If we have a list of action which request to modify the packet in
> different ways, I think there may be a problem. Because packets for the next
> action is already been modified.
> So, let assume we have the flowing scene:
> 1. Packet 1 is send into ethernet0/1
> 2. action 1 request this packet to add vlan tag 1, modify its source mac
> address as 0000.aaaa.aaaa, then send it out to ethenet0/2
> 3. action 2 request do nothing but send it to ethent0/3
> Because the packet 1 has already been modified in step 2, so even in step 3,
> it is requested to do noting but send out to ethernet0/3, I'll still add the
> vlan tag 1, modify the source mac address as 0000.aaaa.aaaa, then send it
> out to ethernet 0/3.

If a client of the datapath doesn't want this behavior, then it can
change the VLAN tag and source MAC back to the original values before
sending it out ethernet0/3, or it can send it out ethernet0/3 before
doing the modifications.

OpenFlow actions work this way anyhow.

[prev in list] [next in list] [prev in thread] [next in thread]