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. > > > 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. > > > 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
