Regards _Sugesh
> -----Original Message----- > From: Darrell Ball [mailto:db...@vmware.com] > Sent: Wednesday, September 27, 2017 7:55 PM > To: Finn Christensen <f...@napatech.com>; Yuanhan Liu <y...@fridaylinux.org> > Cc: d...@openvswitch.org; Chandran, Sugesh <sugesh.chand...@intel.com>; > Simon Horman <simon.hor...@netronome.com> > Subject: Re: [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow > > > > On 9/27/17, 3:41 AM, "Finn Christensen" <f...@napatech.com> wrote: > > -----Original Message----- > From: Yuanhan Liu [mailto:y...@fridaylinux.org] > Sent: 27. september 2017 11:47 > To: Finn Christensen <f...@napatech.com> > Cc: Darrell Ball <db...@vmware.com>; d...@openvswitch.org; Chandran > Sugesh <sugesh.chand...@intel.com>; Simon Horman > <simon.hor...@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. > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
