Hi Daniel.

As I understand it, the goal is to translate these OpenFlow actions:
    sample(sampling_port=1), sample(sampling_port=2), 1, 2
into these datapath actions:
    set(tunnel(...)), sample(...), 1,
    set(tunnel(...)), sample(...), 7471
(For readability, I'm adding line breaks and omitting most arguments.)

The way I'm suggesting to do this is that the translation of OpenFlow
"sample" action should first emit set(tunnel(...), then the sample
action itself.  This can be done in a completely separate way from
the action output.  For example, the following OpenFlow action:
    sample(sampling_port=1)
would translate into these datapath actions;
    set(tunnel(...)), sample(...)
This behavior is going to be less surprising to controller writers.
After all, why should sampling a packet require output?

Now, you may be asking whether this will cause duplicate
set(tunnel(...)) actions.  I do not think so, in the common case,
because ordinarily I'd expect that an output would immediately follow
the sampling.  In that case, the "commit" will not output a duplicate
set(tunnel(...)).  So, for example, this:
    sample(sampling_port=1), 1
would translate into:
    set(tunnel(...)), sample(...), 1

The example you give, where the first sample action is separated from
the output to its port by a different sample action for a different
port, would output two set(tunnel(...)) actions for each port.  However,
if that's a real problem in practice, then the controller can emit
OpenFlow actions in a different order:
    sample(sampling_port=1), 1, sample(sampling_port=2), 2
which may be easier for the controller anyhow.

On Sat, Jun 11, 2016 at 01:31:05AM +0000, Daniel Ye wrote:
> Hi Ben,
> 
> Yes, my first idea is to do adjust_sample_acion()  action in 
> commit_odp_tunnel_action(), but it can hardly
> handle the problem that if there are two or more user world sample action and 
> each has a sampling_port, like the
> last case in my new added testing. We add a flow in the user world like 
> below, port 1 and 2 are both tunnel port:
> "in_port=3, 
> actions=sample(probability=65535,collector_set_id=1,sampling_port=1),sample(probability=65535,collector_set_id=1,sampling_port=2),output:1,2”
> And we want to get the datapath action in the following format:
> Datapath actions: 
> set(tunnel(tun_id=0x5,src=2.2.2.2,dst=1.1.1.1,tos=0x1,ttl=64,flags(df|key))),sample(sample=100.0%,actions(userspace(pid=0,flow_sample(probability=65535,collector_set_id=1,obs_domain_id=0,obs_point_id=0,output_port=1),tunnel_out_port=1))),1,set(tunnel(tun_id=0x6,src=2.2.2.3,dst=1.1.1.2,tos=0x1,ttl=64,flags(df|key))),sample(sample=100.0%,actions(userspace(pid=0,flow_sample(probability=65535,collector_set_id=1,obs_domain_id=0,obs_point_id=0,output_port=7471),tunnel_out_port=7471))),7471
> 
> If we don’t know the output port, I have’t found a way to decide which sample 
> action should be adjusted. So I do the adjust when the output port is known.
> 
> Bests,
> Daniel
>  
> > On Jun 11, 2016, at 6:30 AM, Ben Pfaff <[email protected]> wrote:
> > 
> > <0>
> 

_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

Reply via email to