[ovs-dev] [PATCH v3 9/9] dpif-netdev: do hw flow offload in another thread

[Chandran, Sugesh]

Regards
_Sugesh


> -----Original Message-----
> From: Yuanhan Liu [mailto:yliu at fridaylinux.org]
> Sent: Tuesday, September 26, 2017 6:37 AM
> To: dev at openvswitch.org
> Cc: Finn Christensen <fc at napatech.com>; Darrell Ball <dball at vmware.com>;
> Chandran, Sugesh <sugesh.chandran at intel.com>; Simon Horman
> <simon.horman at netronome.com>; Yuanhan Liu <yliu at fridaylinux.org>
> Subject: [PATCH v3 9/9] dpif-netdev: do hw flow offload in another thread
> 
> Currently, the major trigger for hw flow offload is at upcall handling, which is
> actually in the datapath. Moreover, the hw offload installation and modification
> is not that lightweight. Meaning, if there are so many flows being added or
> modified frequently, it could stall the datapath, which could result to packet
> loss.
> 
> To diminish that, all those flow operations will be recorded and appended to a
> list. A thread is then introduced to process this list (to do the real flow offloading
> put/del operations). This could leave the datapath as lightweight as possible.
[Sugesh] This is really very useful to reduce the flow install overhead on PMD threads.

> 
> Signed-off-by: Yuanhan Liu <yliu at fridaylinux.org>
> ---
>  lib/dpif-netdev.c | 301 ++++++++++++++++++++++++++++++++++++++++++++---
> -------
>  1 file changed, 249 insertions(+), 52 deletions(-)
> 
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c index 13fd012..ef5c2e9 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -1949,6 +1949,223 @@ dp_netdev_pmd_find_flow_by_mark(const
> uint32_t mark)
>      return NULL;
>  }

[Snip] 
> 
> +                          offload->actions, offload->actions_len,
> +                          &offload->ufid, &info, NULL);
> +    if (ret) {
> +        if (create) {
> +            dp_netdev_remove_flow_mark_map(info.flow_mark);
> +        }
> +        return ret;
> +    }
> +
> +    ovs_mutex_lock(&offload->pmd->flow_mutex);
> +    if (create) {
> +        flow->has_mark = true;
> +        flow->mark = info.flow_mark;
> +        if (!flow->dead) {
[Sugesh] Just to confirm, so the assumption here is the flow delete from
revalidator will set the flow as dead and its still keep the structure as its referenced
here. There wont be a situation where flow is deleted and this strcture may freed up.

> +            /*
> +             * A flow could have been dead after we regain the lock,
> +             * while the flow has offloaded to the netdev. When that
> +             * happens, there should be an offload item in the offload
> +             * list for the flow removal. To make sure the flow will

[Snip] 
> --
> 2.7.4