On Tue, Feb 11, 2014 at 03:01:27PM -0800, Ben Pfaff wrote: > On Tue, Feb 04, 2014 at 04:36:18PM -0800, Andy Zhou wrote: > > This patch adds the necessary infrastructure for the next patch series. > > recirculation logic is still work in progress. It is not enabled. There > > should > > be no behavior change. > > The need to always match on recirc_id makes it different from every > other field. At first I was ready to accept this as necessary, but > after some thought I have another idea. > > recirc_id is essentially partitions the flow table into multiple > independent flow tables. In userspace, we already have two concepts for > that: > > - OpenFlow supports multiple flow tables that are completely > independent. > > - The userspace classifier optimizes lookups for tables that are > partitioned based on the "metadata" field. > > Introducing a third way to partition flow tables, by requiring every > flow to match on recirc_id, and then hiding that from OpenFlow is going > to have disadvantages. First, it's conceptually discordant. Second, I > imagine that it's going to be tricky to gracefully hide it completely > from OpenFlow and to maintain that (I'd really rather get rid of our > "hidden flows" than to add more of them). > > Conceptually, this is what I'd like: each recirculation table gets its > own OpenFlow table, and we don't have a recirc_id field in userspace at > all, only a table number. This represents recirculation perfectly, to > the extent of my own understanding of the recirculation design. > Unfortunately, I don't think this is tenable for now, because OpenFlow > has a limit of 255 flow tables (some of which must be reserved for the > controller) and it is probably a bad idea to restrict circulation to a > small number of recirculation IDs (100 or so). (But if that restriction > *is* OK, let me know.) > > So, 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.) > > What do you think?
I have also done some work in this area and I have (finally) posted v18 of my patchset which is targeted towards using recirculation for MPLS. I have done so in the hope that it helps move towards a common solution that works for both MPLS and Bridging. One area in which my implementation differs from Andy's is that it doesn't make use of hidden rules. Rather, it makes use uses hidden facets (though it doesn't call them that). These are visible when dumped from the datapath but not on the OpenFlow side because they simply don't exist there. One thing that concerns me with using special tables and the like is that it may not work well in conjunction with goto table and resubmit. Although my implementation does not yet work with those actions either. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
