-----Original Message-----
From: Darrell Ball [mailto:[email protected]]
Sent: 27. september 2017 05:54
To: Yuanhan Liu <[email protected]>
Cc: [email protected]; Finn Christensen <[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/26/17, 8:27 PM, "Yuanhan Liu" <[email protected]> wrote:
On Wed, Sep 27, 2017 at 03:13:33AM +0000, Darrell Ball wrote:
>
>
> On 9/26/17, 6:25 PM, "Yuanhan Liu" <[email protected]> wrote:
>
> On Tue, Sep 26, 2017 at 09:58:16PM +0000, Darrell Ball wrote:
> > The second major change is there is a thread introduced to
do
the real
> > flow offload. This is for diminishing the overhead by hw
flow
offload
> > installation/deletion at data path. See patch 9 for more
detailed
info.
> >
> > [Darrell] There might be other options to handle this such as
dividing time
> > to HWOL in a given PMD.
> > Another option to have PMD isolation.
>
> Good to know, though I'm not sure I understand it so far. But it
can
be
> discussed later. That's also the reason I put it in the last
patch, so
> that we could easily turn it to another solution, or even simpler
(just
> remove it).
>
> > In the last discussion, RSS action was suggested to use to
get rid
of
> > the QUEUE action workaround. Unfortunately, it didn't work.
The
flow
> > creation failed with MLX5 PMD driver, and that's the only
driver in
> > DPDK that supports RSS action so far.
> >
> >
> > [Darrell]
> > I wonder if we should take a pause before jumping into the next
version of the code.
>
> I have no objections.
>
> > If workarounds are required in OVS code, then so be it as long
as
they are not
> > overly disruptive to the existing code and hard to maintain.
> > In the case of RTE_FLOW_ACTION_TYPE_RSS, we might have a
reasonable option
> > to avoid some unpleasant OVS workarounds.
> > This would make a significant difference in the code paths, if
we
supported it, so
> > we need to be sure as early as possible.
>
> I agree.
>
> > The support needed would be in some drivers and seems
reasonably doable.
> > Moreover, this was discussed in the last dpdk meeting and the
support was
> > indicated as existing?, although I only verified the MLX code,
myself.
>
> From the code point of view, yes, the code was there months ago.
>
> > I had seen the MLX code supporting _RSS action and there are
some checks for
> > supported cases; when you say “it didn't work”, what was the
issue
?
>
> I actually have met the error months ago, I even debugged it.
IIRC,
> the error is from libibverbs, when trying to create the hw flow. I
> think I need double-confirm it with our colleague who developed
this
> feature.
>
> > Let us have a discussion also about the Intel nic side and the
Napatech side.
>
> I think it's not necessary for Napatech, because they can support
> MARK only action.
>
> It is not necessary for Napatech; however to avoid the need to detect
the Napatech
> special (good) case, ‘ideally’ we do the exact same programming even
in Napatech case.
Will following look okay to you (assuming we have the probe ability and
DPDK
has some basic capability feedback)?
if (!pure_mark_cap_probed) {
if (dpdk_rte_flow_has_rss_action_support) {
append_rss_action();
} else {
fail and return;
}
}
/* create flow once, with no retries, if fails, let it fail */
flow = rte_flow_create(...);
I assume that's how the code looks like finally. What do you think?
[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.
--yliu
> For Intel, yes, I think Intel folks could give some comments here.
>
> > It seems reasonable to ask where the disconnect is and whether
this support
> > can be added and then make a decision based on the answers.
>
> No objections.
>
> --yliu
>
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
