On Tue, Feb 11, 2014 at 05:52:43PM -0800, Andy Zhou wrote:
> On Tue, Feb 11, 2014 at 5:12 PM, Ben Pfaff <b...@nicira.com> wrote:
>
> > On Tue, Feb 11, 2014 at 05:00:33PM -0800, Andy Zhou wrote:
> > > On Tue, Feb 11, 2014 at 3:01 PM, Ben Pfaff <b...@nicira.com> wrote:
> > > > Here's another proposal. Take one OpenFlow table (say, table 254)
> > > > and use it for recirculation. Populate the metadata field (yes, it's
> > 64
> > > > bits, but that's OK) with the recirculation ID, and make every flow in
> > > > the table match on metadata. When a packet comes to userspace, if it
> > > > has a nonzero kernel recirc_id, then look it up in this special
> > OpenFlow
> > > > table, filling in metadata with recirc_id; if it has a zero recirc_id,
> > > > just look it up in table 0 as usual. (One could avoid this special
> > case
> > > > on recirc_id, if that is desirable, by adding a special flow to this
> > > > special table: "metadata=0, actions=resubmit:0". One could also move
> > > > the in-band control and fail-open rules in this table, with a
> > metadata=0
> > > > match, and then avoid the need for hidden flows in table 0.)
> > >
> > > The hidden flows are 1) not visible to the controller, 2) can not be
> > > installed or deleted from the controller. Would we risk those two
> > > properties by placing them in table 254? May be we can use a internal
> > > table that is off-limits to the open flow tables?
> >
> > We already use table 254 for certain "internal" flows that we don't want
> > controllers to meddle with[*]. So, these issues have been worked out
> > somewhat, by making table 254 sort-of hidden:
> >
> > - A controller that asks for a list of tables doesn't get told
> > about that one.
> >
> > - A controller that tries to modify table 254 gets back a
> > permission error.
> >
> > - A controller that asks to dump all flows doesn't get flows
> > from table 254.
> >
> > but:
> >
> > - A controller that asks to dump flows in table 254 specifically
> > does get them. (I put that in because it seemed useful for
> > debugging.)
> >
> > Probably the same rules would work OK for the recirc flows.
> >
> > [*] I forgot the number I used while I wrote the previous message. I
> > guess that 253 would be a better choice for our new table, then.
>
> This sounds good. I can see how bond mega flow can work under those
> restrictions.
>
> Purely in theory, would this potentially causing confusion to controllers
> that think they
> can use all tables? I don't know all the details of the openflow spec.
It should not confuse controllers. First, controllers should only be
using tables that the switch tells them exist, and the rules above
ensure that OVS does not tell controllers that these tables exist.
Second, most controllers aren't designed to use tons of tables anyway,
because most hardware only has one or two tables. Third, the OVS
documentation (in DESIGN) says not to use them:
Tables 128 and above are reserved for use by the switch itself.
Controllers should use only tables 0 through 127.
> > > Bonding metaflow does not need it, but one can envision that
> > > controller may want to manage (some subset of) recirc_ids in the
> > > future. In those cases, table 254 is a good candidate.
> >
> > Sure. Or one could give a subset of recirc ids to the controller, I
> > guess, by making table 254 resubmit those to some more ordinary table.
> >
> > > Using metadata to store recirc_id is fine, as long as the rules does not
> > > have resubmits or goto tables. I can only think of 3 actions:
> > > 1. output to a port (bonding), 2) another recirc action (mpls) 3) slow
> > path
> > > (flow miss fairness)
> >
> > Why are resubmits or goto-tables bad?
>
> In case they don't metadata is not reset before resubmit. We can either
> force metadata to zero
> before resubmit if it is leaving table 254, or simply treat it as a
> (controller) bug.
I guess if any of our recirculation rules need to resubmit, they can
simply "load:0->OXM_OF_METADATA[]" before the resubmit. And when (if,
as Jesse said) we allow controllers to do their own recirculation, I
suspect that we'll just document that the initial metadata contains the
recirculation id.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
