[ovs-dev] [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow

Chandran, Sugesh sugesh.chandran at intel.com
Mon Oct 2 16:22:29 UTC 2017



Regards
_Sugesh


> -----Original Message-----
> From: Darrell Ball [mailto:dball at vmware.com]
> Sent: Wednesday, September 27, 2017 7:55 PM
> To: Finn Christensen <fc at napatech.com>; Yuanhan Liu <yliu at fridaylinux.org>
> Cc: dev at openvswitch.org; Chandran, Sugesh <sugesh.chandran at intel.com>;
> Simon Horman <simon.horman at netronome.com>
> Subject: Re: [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow
> 
> 
> 
> On 9/27/17, 3:41 AM, "Finn Christensen" <fc at napatech.com> wrote:
> 
>         -----Original Message-----
>         From: Yuanhan Liu [mailto:yliu at fridaylinux.org]
>         Sent: 27. september 2017 11:47
>         To: Finn Christensen <fc at napatech.com>
>         Cc: Darrell Ball <dball at vmware.com>; dev at openvswitch.org; Chandran
>         Sugesh <sugesh.chandran at intel.com>; Simon Horman
>         <simon.horman at netronome.com>
>         Subject: Re: [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow
> 
>         On Wed, Sep 27, 2017 at 09:12:49AM +0000, Finn Christensen wrote:
>         >
>         >     [Darrell] It looks fine; of course, if we could drop dependencies on cap
>         >     probe, it would be ideal (.
>         >
>         >
>         > [Finn]
>         > From a Napatech point of view, we would definitely want to use the
>         > RTE_FLOW_ACTION_TYPE_RSS if it were implement. It definitely makes
>         > good sense to me. I have 2 reasons for this:
>         > 1. It would fit nicely into the way Napatech does flow programming in
>         > nic 2. We would be fully RSS controlled through OVS Furthermore,
>         > Future RSS splitting on a per megaflow basis will be possible.
>         > IMO the "pure_mark_cap_probed" function is a temp work-around to
>         make it work.
>         > The RSS seems to be a solution to the queue problem.
> 
>         Finn, that's really good to know! I do agree without this probe, it makes the
>         code simpler and cleaner.
> 
>         Few questions though. Have Napatech already implemented rss action? If
>         not, what's the plan?
> 
>     [Finn]
>     Our nic handles rss on a per flow basis, but we have not yet used rte rss action
>     for OVS. In OVS we simply handles RSS config outside it.
>     The full control of rss through OVS is better though.
> 
>         And are you okay with following code?
> 
>         add_mark_action();
>         add_rss_action_unconditionally();
> 
>         flow = rte_create_flow(...);
>         if (!flow)
>         return -1;
> 
>         That is, no probes, no feedbacks. If it failed, it just failed (flow offload then
>         is just skipped).
> 
>     [Finn]
>     Yes, we can easily make this work. Good suggestion!
> 
> 
>         But I do think some feedbacks are necessary. If we know the rte_flow cap
>         in the begnning, we could simply disable the flow offload for a specific port
>         if we know it doesn't have offload ability. This would avoid the repeat
>         effort of trying to do hw offload completely.
> 
>     [Finn]
>     This seems to be a good idea.
> 
> [Darrell] Regarding the general question of capability checking, it is fine to have
> this support
>                in general and we already identified some cases where it would be best
> to use this
>                if we can (the question mostly comes down to support by RTE and
> drivers).
> 
>               Probing is different and we usually use the term for some try and error
> checking to configure
>               something during initialization and see if works and then mark the
> associated capability as enabled
>              or disabled.  We could also use a different kind of probing here in a
> dynamic fashion, where we try to do
>              HWOL and if it fails X times we don’t try again unless we detect the port
> has been reconfigured,
>              for example, in case the capability check is not possible or not
> implemented yet.
[Sugesh] I agree with Darrel here and we are also looking at implementing a capability APIs
to expose the device feature sets. I will check with our DPDK team and will post the update.
> 
> 
> 
> 
>         --yliu
>     Disclaimer: This email and any files transmitted with it may contain
> confidential information intended for the addressee(s) only. The information is
> not to be surrendered or copied to unauthorized persons. If you have received
> this communication in error, please notify the sender immediately and delete
> this e-mail from your system.
> 



More information about the dev mailing list