[ovs-dev,V2,03/14] netdev-offload-dpdk: Implement flow dump create/destroy APIs

When offloading vports, we don't configure rte_flow on the vport itself,
as it is not a physical dpdk port, but rather on uplinks. Implement
those APIs as a pre-step to enable iterate over the ports.

Signed-off-by: Eli Britstein <elibr@nvidia.com>
Reviewed-by: Gaetan Rivet <gaetanr@nvidia.com>
---
 lib/netdev-offload-dpdk.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein <elibr@nvidia.com> wrote:
>
> When offloading vports, we don't configure rte_flow on the vport itself,
> as it is not a physical dpdk port, but rather on uplinks. Implement
> those APIs as a pre-step to enable iterate over the ports.

We don't need these flow_dump APIs, since we are not really dumping
any flows here and also orig_in_port is provided to the offload layer
(Patch 12).

Thanks,
-Harsha


>
> Signed-off-by: Eli Britstein <elibr@nvidia.com>
> Reviewed-by: Gaetan Rivet <gaetanr@nvidia.com>
> ---
>  lib/netdev-offload-dpdk.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
>
> diff --git a/lib/netdev-offload-dpdk.c b/lib/netdev-offload-dpdk.c
> index f2413f5be..8cc90d0f1 100644
> --- a/lib/netdev-offload-dpdk.c
> +++ b/lib/netdev-offload-dpdk.c
> @@ -1588,6 +1588,28 @@ netdev_offload_dpdk_flow_flush(struct netdev *netdev)
>      return 0;
>  }
>
> +static int
> +netdev_offload_dpdk_flow_dump_create(struct netdev *netdev,
> +                                     struct netdev_flow_dump **dump_out,
> +                                     bool terse OVS_UNUSED)
> +{
> +    struct netdev_flow_dump *dump;
> +
> +    dump = xzalloc(sizeof *dump);
> +    dump->netdev = netdev_ref(netdev);
> +
> +    *dump_out = dump;
> +    return 0;
> +}
> +
> +static int
> +netdev_offload_dpdk_flow_dump_destroy(struct netdev_flow_dump *dump)
> +{
> +    netdev_close(dump->netdev);
> +    free(dump);
> +    return 0;
> +}
> +
>  const struct netdev_flow_api netdev_offload_dpdk = {
>      .type = "dpdk_flow_api",
>      .flow_put = netdev_offload_dpdk_flow_put,
> @@ -1595,4 +1617,6 @@ const struct netdev_flow_api netdev_offload_dpdk = {
>      .init_flow_api = netdev_offload_dpdk_init_flow_api,
>      .flow_get = netdev_offload_dpdk_flow_get,
>      .flow_flush = netdev_offload_dpdk_flow_flush,
> +    .flow_dump_create = netdev_offload_dpdk_flow_dump_create,
> +    .flow_dump_destroy = netdev_offload_dpdk_flow_dump_destroy,
>  };
> --
> 2.28.0.546.g385c171
>

On 2/23/2021 3:10 PM, Sriharsha Basavapatna wrote:
> On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein<elibr@nvidia.com>  wrote:
>> When offloading vports, we don't configure rte_flow on the vport itself,
>> as it is not a physical dpdk port, but rather on uplinks. Implement
>> those APIs as a pre-step to enable iterate over the ports.
> We don't need these flow_dump APIs, since we are not really dumping
> any flows here and also orig_in_port is provided to the offload layer
> (Patch 12).

We still need them to traverse the ports to get the vxlan netdev in case 
of a miss. See patch #5:

37056941f netdev-offload-dpdk: Implement HW miss packet recover for vport

There, see get_vport_netdev.

The naming is because this is "flow_api" and the implementation is of an 
existing API rather than introducing new one(s).

>
> Thanks,
> -Harsha
>
>

On Tue, Feb 23, 2021 at 6:55 PM Eli Britstein <elibr@nvidia.com> wrote:
>
>
> On 2/23/2021 3:10 PM, Sriharsha Basavapatna wrote:
>
> On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein <elibr@nvidia.com> wrote:
>
> When offloading vports, we don't configure rte_flow on the vport itself,
> as it is not a physical dpdk port, but rather on uplinks. Implement
> those APIs as a pre-step to enable iterate over the ports.
>
> We don't need these flow_dump APIs, since we are not really dumping
> any flows here and also orig_in_port is provided to the offload layer
> (Patch 12).
>
> We still need them to traverse the ports to get the vxlan netdev in case of a miss. See patch #5:
>
> 37056941f netdev-offload-dpdk: Implement HW miss packet recover for vport
>
> There, see get_vport_netdev.
>
> The naming is because this is "flow_api" and the implementation is of an existing API rather than introducing new one(s).

I've suggested a new API (see my comments in Patch 5).
>
> Thanks,
> -Harsha
>
>