[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-dev
Subject:    [ovs-dev] [PATCH] [RFC] Add OpenFlow 1.3 protocol support for meters.
From:       jesse () nicira ! com (Jesse Gross)
Date:       2013-06-28 22:05:30
Message-ID: CAEP_g=-FJz2oH_VpLfgXxVP2MBwcXoBq2dyHOdRijyahj7cXXA () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jun 25, 2013 at 1:08 AM, Rajahalme, Jarno (NSN - FI/Espoo)
<jarno.rajahalme at nsn.com> wrote:
> I also tried to figure out how the group table should be implemented. I haven't \
> done anything for it yet, but I'm rather convinced that the datapath should \
> maintain the group table so that there would be no need for facet revalidation when \
> group table entries change. The alternative of translating the group actions to the \
> facet action lists would result in rather expensive facet revalidations whenever \
> there is a change in the group tables. This is made even more complex by groups \
> within groups, etc.  However, if the datapath maintains the group table separately \
> from the flow table, changes to the group tables would be very cheap due to the \
> indirection provided: if an existing entry in the group table changes, the flow \
> action referring to that group will find the updated entry for the very next packet \
> being processed without any facet revalidations. This would make, e.g., some route \
> table updates very efficient.

I would want to see some pretty compelling numbers on this before
proceeding down this path. For example, I don't think that the cost of
facet revalidation should be a factor here since you could keep a
group indirection table in userspace and swap out the appropriate
ports without recomputing the full action list from scratch. This
might be complicated when you have complex sets and types of groups
but to me that's an argument for doing it in userspace, since there is
more information and flexibility there.
X-CudaMail-Whitelist-To: dev at openvswitch.org


[prev in list] [next in list] [prev in thread] [next in thread]