[ovs-dev] [PATCH 0/6] Bond port megaflow using recirculation

[Andy Zhou]

This is an interesting idea. I have a few questions in line:


On Tue, Feb 11, 2014 at 3:01 PM, Ben Pfaff <blp at nicira.com> 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).
>
This is very true. I am facing this issue now.

>
> 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.)
>
> I like the direction of using OpenFlow tables.  We probably don't want to
restrict the number of recirc ids.

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

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.

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)

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.

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 ?


> What do you think?
>
I like the direction, It will make adding recirc_id in the user space more
natural.

>
> Thanks,
>
> Ben.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140211/ca9d4f1f/attachment-0003.html>