[ovs-dev] [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow
fc at napatech.com
Tue Oct 3 08:44:47 UTC 2017
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
> -----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;
> Sugesh <sugesh.chandran at intel.com>; Simon Horman
> <simon.horman at netronome.com>
> Subject: Re: [PATCH v3 0/9] OVS-DPDK flow offload with
> On Wed, Sep 27, 2017 at 09:12:49AM +0000, Finn Christensen wrote:
> > [Darrell] It looks fine; of course, if we could drop dependencies
> > probe, it would be ideal (.
> > [Finn]
> > From a Napatech point of view, we would definitely want to use
> > RTE_FLOW_ACTION_TYPE_RSS if it were implement. It definitely
> > good sense to me. I have 2 reasons for this:
> > 1. It would fit nicely into the way Napatech does flow programming
> > 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
> 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
> code simpler and cleaner.
> Few questions though. Have Napatech already implemented rss
> not, what's the plan?
> Our nic handles rss on a per flow basis, but we have not yet used rte rss
> 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?
> flow = rte_create_flow(...);
> if (!flow)
> return -1;
> That is, no probes, no feedbacks. If it failed, it just failed (flow offload
> is just skipped).
> Yes, we can easily make this work. Good suggestion!
> But I do think some feedbacks are necessary. If we know the
> in the begnning, we could simply disable the flow offload for a
> if we know it doesn't have offload ability. This would avoid the repeat
> effort of trying to do hw offload completely.
> 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.
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
> 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