-----Original Message-----
From: Chandran, Sugesh [mailto:[email protected]]
Sent: 2. oktober 2017 18:22
To: Darrell Ball <[email protected]>; Finn Christensen
<[email protected]>; Yuanhan Liu <[email protected]>
Cc: [email protected]; Simon Horman
<[email protected]>
Subject: RE: [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow
Regards
_Sugesh
> -----Original Message-----
> From: Darrell Ball [mailto:[email protected]]
> Sent: Wednesday, September 27, 2017 7:55 PM
> To: Finn Christensen <[email protected]>; Yuanhan Liu
> <[email protected]>
> Cc: [email protected]; Chandran, Sugesh
<[email protected]>;
> Simon Horman <[email protected]>
> Subject: Re: [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow
>
>
>
> 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.
[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.
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
