Hello Feruh,
> Subject: Re: [dpdk-dev] [PATCH v4 2/4] ethdev: tunnel offload model
>
> External email: Use caution opening links or attachments
>
>
> On 10/7/2020 1:36 PM, Gregory Etelson wrote:
> > Hello Harsha,
> >
> >> -Original Message-
>
Formatting review below (someone has to do it):
04/10/2020 15:50, Gregory Etelson:
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -3034,6 +3034,111 @@ operations include:
> +Tunneled traffic offload
> +
> +
> +Provide software app
On 10/7/2020 1:36 PM, Gregory Etelson wrote:
Hello Harsha,
-Original Message-
[snip]
Tunnel vport is an internal construct used by one specific
application: OVS. So, shouldn't the rte APIs also be application
agnostic apart from being vendor agnostic ? For OVS, the match fields
in t
Hello Harsha,
> -Original Message-
[snip]
>
> Tunnel vport is an internal construct used by one specific
> application: OVS. So, shouldn't the rte APIs also be application
> agnostic apart from being vendor agnostic ? For OVS, the match fields
> in the existing datapath flow rules contai
On Sun, Oct 4, 2020 at 7:23 PM Gregory Etelson wrote:
>
> From: Eli Britstein
>
> Rte_flow API provides the building blocks for vendor agnostic flow
> classification offloads. The rte_flow match and action primitives are
> fine grained, thus enabling DPDK applications the flexibility to
> offloa
From: Eli Britstein
Rte_flow API provides the building blocks for vendor agnostic flow
classification offloads. The rte_flow match and action primitives are
fine grained, thus enabling DPDK applications the flexibility to
offload network stacks and complex pipelines.
Applications wishing to off
6 matches
Mail list logo
