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