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

Finn Christensen fc at napatech.com
Tue Oct 3 08:44:47 UTC 2017



    -----Original Message-----
    From: Chandran, Sugesh [mailto:sugesh.chandran at intel.com]
    Sent: 2. oktober 2017 18:22
    To: Darrell Ball <dball at vmware.com>; Finn Christensen
    <fc at napatech.com>; Yuanhan Liu <yliu at fridaylinux.org>
    Cc: dev at openvswitch.org; Simon Horman
    <simon.horman at netronome.com>
    Subject: RE: [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow
    
    
    
    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.

[Finn]
I also agree here, however, the "X times failed and then mark port as HWOL 
disabled", should only be done initially, where no successfully offloads has 
yet occurred.

    >
    >
    >
    >
    >         --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