Paolo Valerio <[email protected]> writes:
> Connections that need to be removed, e.g. while forcing a direction,
> were invalidated forcing them to be expired.
> This is not actually needed, as it's typically a one-time
> operation.
> The patch replaces a call to conn_force_expire() with a call to
> conn_clean().
>
> Signed-off-by: Paolo Valerio <[email protected]>
> ---
Is there a possible contention issue now where the conn update can also
take the ct lock? IE: before, we would rely on the expiration timer
processing, but now we directly release which requires the ct lock.
Maybe since it is a rare enough event, this isn't as big a deal?
> lib/conntrack.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/lib/conntrack.c b/lib/conntrack.c
> index ce8a63de5..7e1fc4b1f 100644
> --- a/lib/conntrack.c
> +++ b/lib/conntrack.c
> @@ -514,12 +514,6 @@ conn_clean(struct conntrack *ct, struct conn *conn)
> atomic_count_dec(&ct->n_conn);
> }
>
> -static void
> -conn_force_expire(struct conn *conn)
> -{
> - atomic_store_relaxed(&conn->expiration, 0);
> -}
> -
> /* Destroys the connection tracker 'ct' and frees all the allocated memory.
> * The caller of this function must already have shut down packet input
> * and PMD threads (which would have been quiesced). */
> @@ -1089,7 +1083,7 @@ conn_update_state(struct conntrack *ct, struct
> dp_packet *pkt,
> break;
> case CT_UPDATE_NEW:
> if (conn_lookup(ct, &conn->key, now, NULL, NULL)) {
> - conn_force_expire(conn);
> + conn_clean(ct, conn);
> }
> create_new_conn = true;
> break;
> @@ -1299,7 +1293,7 @@ process_one(struct conntrack *ct, struct dp_packet *pkt,
> /* Delete found entry if in wrong direction. 'force' implies commit. */
> if (OVS_UNLIKELY(force && ctx->reply && conn)) {
> if (conn_lookup(ct, &conn->key, now, NULL, NULL)) {
> - conn_force_expire(conn);
> + conn_clean(ct, conn);
> }
> conn = NULL;
> }
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
