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?
--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
