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

[Darrell Ball]

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.


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