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

List:       openvswitch-discuss
Subject:    [ovs-discuss] =?gb2312?b?tPC4tDogIFByb2JsZW0gd2l0aCBkZXNpZ25pbmcg?= =?gb2312?b?dGhlIGZlYXR1cmUgb2Ygb
From:       chenzh () centecnetworks ! com (chenzh)
Date:       2012-07-24 1:46:49
Message-ID: 3B468FC3EB7E4EBF91DCEC2CD9CBD77D () centecnetworks ! com
[Download RAW message or body]

->I can't find any clues about it from the newest openflow switch
specification(version 1.1).
Sorry I typed wrongly, Its v1.3.
Plus do you mean the following description:
5.11:
The semantics of the action list is identical to the OpenFlow 1.0
specication. The actions of an action list are executed in the order specied
by the list, and are applied immediately to the packet.

Best regards,

???   ???
Centec Networks Inc
????????????
Web: www.centecnetworks.com
??????????5??????B?4?13/16??
??: 215021
??: 0512-62885358
??: 0512-62885870  

-----????-----
???: chenzh [mailto:chenzh at centecnetworks.com] 
????: 2012?7?24? 9:09
???: 'Ben Pfaff'
??: 'discuss at openvswitch.org'
??: ??: [ovs-discuss] Problem with designing the feature of
muitiple-action

>OpenFlow actions work this way anyhow.
Is there any specification documents that directly point out the openflow
action should work in this way, or just the ovs do?
I can't find any clues about it from the newest openflow switch
specification(version 1.1).
I don't quite understand why action working like this would be better.

Best regards,

???   ???
Centec Networks Inc
????????????
Web: www.centecnetworks.com
??????????5??????B?4?13/16??
??: 215021
??: 0512-62885358
??: 0512-62885870  
-----????-----
???: Ben Pfaff [mailto:blp at nicira.com] 
????: 2012?7?24? 1:02
???: chenzh
??: discuss at openvswitch.org
??: Re: [ovs-discuss] Problem with designing the feature of
muitiple-action

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]