On 9/27/17, 3:41 AM, "Finn Christensen" <[email protected]> wrote:
-----Original Message-----
From: Yuanhan Liu [mailto:[email protected]]
Sent: 27. september 2017 11:47
To: Finn Christensen <[email protected]>
Cc: Darrell Ball <[email protected]>; [email protected]; Chandran
Sugesh <[email protected]>; Simon Horman
<[email protected]>
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.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
