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

List:       openvswitch-discuss
Subject:    [ovs-discuss] Learned flows lacking resubmit option
From:       blp () nicira ! com (Ben Pfaff)
Date:       2011-11-15 5:57:05
Message-ID: 20111115055705.GF12189 () nicira ! com
[Download RAW message or body]

On Tue, Nov 15, 2011 at 02:52:21PM +0900, Jari Sundell wrote:
> On Tue, Nov 15, 2011 at 2:31 PM, Ben Pfaff <blp at nicira.com> wrote:
> >> Basically I got a host with multiple virtual machines, and to keep the
> >> flow table sizes reasonable I've split up the filtering and routing
> >> into two parts; filtering what an instance is allowed to send, etc, in
> >> the first stage, then in the second stage do filtering what an
> >> instance is allowed to receive and sending to the right port.
> >>
> >> So in order to avoid asking the controller for every single new
> >> connection made from the instance, the first stage needs to be able to
> >> add flows that can pass packets to the second stage table. If the
> >> requested feature is not available, I'll have to look into adding
> >> extra tables duplicating the second stage which instead saves the
> >> output port in the registry... Basically it'll get very messy.
> >
> > Can't you just do
> > ? ? ? ?learn(table=2, ...), resubmit(,2), resubmit(,3)
> > where table 2 is the learning table and table 3 is the second stage?
> 
> The thing is that the flow that is learned is the one that needs to be
> able to send packets to table 3 in order to properly route later
> packets, not just the packet that sets up the connection.
> 
> While the usual usecase for learn might be properly served by just the
> output action, that really isn't sufficient with more complicated uses
> like this. There might later even be need for learning flows (and/or
> sending to controller) for packets in the second stage after going
> through the first stage.

OK, so your learned flow in table 2 sets a value into a register, then
table 3 bases its action on the value in that register.  Doesn't that
work?

The goal of the "learn" action isn't to be able to set up an arbitrary
action--that would be even more of a pain than "learn" already is--it's
to be a primitive that is composable enough that a carefully designed
flow table can do (almost) arbitrary actions with it as a building
block.

I didn't even want to add "output" as a possible "learn" action but I
was overruled at a higher level.

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