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