On 9/15/20 9:20 PM, Flavio Leitner wrote:
> The datapath flow limit is calculated by revalidators so
> log the value as well.
> 
> Signed-off-by: Flavio Leitner <[email protected]>
> ---
>  ofproto/ofproto-dpif-upcall.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
> index 72a5b4d73..05a912f57 100644
> --- a/ofproto/ofproto-dpif-upcall.c
> +++ b/ofproto/ofproto-dpif-upcall.c
> @@ -1283,7 +1283,8 @@ should_install_flow(struct udpif *udpif, struct upcall 
> *upcall)
>      atomic_read_relaxed(&udpif->flow_limit, &flow_limit);
>      if (udpif_get_n_flows(udpif) >= flow_limit) {
>          COVERAGE_INC(upcall_flow_limit_hit);
> -        VLOG_WARN_RL(&rl, "upcall: datapath flow limit reached");
> +        VLOG_WARN_RL(&rl, "upcall: datapath flow limit reached (max: %u)",

I think that we're not printing this value just because it's dynamically
adjustable by revalidators.  From that perspective, I don't think that
'max' is a good word to describe the value, because users might think
that they have a direct control over it and might think that it's the
value set by the 'flow_limit' configuration knob.
'current dynamic limit' or something similar might be better choice, but
I'm not sure.

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to