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.
> 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?
> 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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
