Thanks.
On Wed, Feb 19, 2014 at 02:34:40PM -0800, Joe Stringer wrote:
> Ah, I see now. That would be my misunderstanding, from following the
> "flow-limit" and "flow_limit" configuration options and equating them with
> each other. I plan to send a fresh version.
>
>
> On 19 February 2014 14:20,
Ah, I see now. That would be my misunderstanding, from following the
"flow-limit" and "flow_limit" configuration options and equating them with
each other. I plan to send a fresh version.
On 19 February 2014 14:20, Ben Pfaff wrote:
> bridge_reconfigure() reads other-config:max-idle from the Ope
bridge_reconfigure() reads other-config:max-idle from the Open_vSwitch
table. That part is fine. I'm complaining about max_idle in the
Flow_Table table. Why do both exist?
On Wed, Feb 19, 2014 at 02:00:44PM -0800, Joe Stringer wrote:
> Hmm. The way I follow it is that bridge_reconfigure() will
Hmm. The way I follow it is that bridge_reconfigure() will read it from the
table, and call ofproto_set_max_idle() to set the ofproto_flow_idle
variable. Later, in revalidate_udumps(), we take a local copy of
ofproto_flow_idle, and this is used later in the function (by code that
already exists).
On Tue, Feb 18, 2014 at 11:01:39AM -0800, Joe Stringer wrote:
> Signed-off-by: Joe Stringer
This patch adds a new "max_idle" column to the Flow_Table table, and
documents it, but doesn't appear to use it anywhere in actual code.
___
dev mailing list
dev
Signed-off-by: Joe Stringer
---
v3: Use 'unsigned' instead of 'long long int' for ofproto_max_idle.
v2: Don't cache the max_idle in 'struct udpif'.
Extend range of valid values to 100-3.
---
ofproto/ofproto-dpif-upcall.c |5 ++---
ofproto/ofproto-provider.h|4
ofproto/of
