[ovs-dev] [PATCH 0/6] Bond port megaflow using recirculation
azhou at nicira.com
Wed Feb 12 01:52:43 UTC 2014
On Tue, Feb 11, 2014 at 5:12 PM, Ben Pfaff <blp at 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 <blp at 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
> > > 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
> > > 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
> > > 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
> > > 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.
> - A controller that asks to dump flows in table 254 specifically
> does get them. (I put that in because it seemed useful for
> 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
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.
> > 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
> > (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
> > If you don't think resubmits are not in picture, may be we should also
> > consider storing dp_hash into
> > one of the registers, so we don't have to expend the flow size.
> I'd be OK with that, I think.
> > In case we may need to support support multiple tables for recirculation
> > rules, we should also
> > work out how we pick tables, may be encode it in a few bits in the
> > recirc_id ?
> I think that would be fine.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev