On 9/26/17, 8:27 PM, "Yuanhan Liu" <y...@fridaylinux.org> wrote:
On Wed, Sep 27, 2017 at 03:13:33AM +0000, Darrell Ball wrote:
>
>
> On 9/26/17, 6:25 PM, "Yuanhan Liu" <y...@fridaylinux.org> 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 (.
--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
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
