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

Andy Zhou azhou at nicira.com
Wed Feb 12 01:52:43 UTC 2014


On Tue, Feb 11, 2014 at 5:12 PM, Ben Pfaff <blp at 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 <blp at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140211/7ed323bd/attachment-0003.html>


More information about the dev mailing list