[ovs-dev] [RFC PATCH] dpif-netdev: Support "port-forward" mode to avoid dp cache lookup

[Ilya Maximets]

On 4/27/21 11:56 AM, Sriharsha Basavapatna via dev wrote:
> Hi Eli,
> 
> On Sun, Apr 25, 2021 at 6:22 PM Eli Britstein <elibr at nvidia.com> wrote:
>>
>> Hi Harsha,
>>
>> On 4/20/2021 11:07 AM, Sriharsha Basavapatna wrote:
>>> Sometimes a port might be configured with a single flow that just
>>> forwards packets to another port. This would be useful in configs
>>> where the bridge is just fowarding packets between two ports (for
>>> example, between a vhost-user port and a physical port). A flow
>>> that matches only on the in_port and with an action that forwards
>>> to another port would be configured, to avoid learning or matching
>>> on packet headers.
>>>
>>> Example:
>>> $ ovs-ofctl add-flow br0 in_port=1,actions=output:2
>>> $ ovs-ofctl add-flow br0 in_port=2,actions=output:1
>>>
>>> This translates to a datapath flow with the match fields wildcarded
>>> for the packet headers. However, the datapath processing still involves
>>
>> There are still several matches (not wildcards):
>>
>>    - recirc_id
>>    - in_port
>>    - packet_type
>>    - dl_type
>>    - vlan_tci
>>    - nw_frag (for ip packets)
>>
>> So there might be multiple flows for each such openflow rule.
>>
>> In the past, I have tried to optimize such scenario, see:
>>
>> https://mail.openvswitch.org/pipermail/ovs-dev/2019-April/357882.html
>>
>> That was wrong as commented afterwards.
>>
>> Another related patch-set was this (also not accepted):
>>
>> https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/363948.html
>>
>> Ilya wrote an alternative patch:
>>
>> https://patchwork.ozlabs.org/patch/1105880/
>>
>> AFAIR, it didn't improve performance either.

Would be good to have some performance numbers for it as there was
no test results published and I don't know if someone ever tested it.

> 
> Thanks for the above pointers. Ilya had also shared this patch
> recently while discussing this topic at the ovs-dpdk community
> meeting. I want to see if we can utilize part of the logic in that
> patch to add some constraints, while still avoiding an additional
> table/lookup.  The 'port-forward' mode implies that the user wants to
> avoid any kind of lookup in the datapath (as indicated by the ofctl
> rule + port-forward mode).

I don't see how to completely avoid lookups.

IIUC, in this patch there is a match and upcall for the first packet,
but there are no matches for subsequent packets.  This will work
only for flow actions that doesn't modify the packet.  If for some
reason the flow contains header modifications OVS will not do that
correctly because the header is not parsed.  Also, if the packet is
a bit different from the very first packet, we might attempt to
modify headers that doesn't exist.  All in all, this is very dangerous
and might lead to OVS crash.  We can't rely on the user to set specific
OF rules for this functionality and we should not have a feature that
might crash OVS if not used accurately.

The way to not parse the packet at all and to not perform any matches is
the way to completely ignore OF rules, but OVS is an OF switch and
such functionality just doesn't fit.

In my change I minimized the lookup as possible to a single 64bit key.
And it will actually work with any OF rules and without enabling of
any special flags.  Would be great to see some performance numbers
for it as I didn't see any.

> With pvp tests (vxlan config), we have
> seen better performance both in pps: ~50% and cpp: ~35%, at a few
> thousand flows. Similar improvement can be seen with simple
> configurations (e.g testpmd in the vm in txonly fwd mode).
> 
>>
>> Besides, I've tried this patch. Maybe I did something wrong (I
>> configured port-forward=true on those ports and those openflow rules,
>> and pinged between those ports). I didn't see it worked (the coverage,
>> and also I added my own prints).
> 
> When you enable port-forward and start the traffic, you should see a
> message like this:
> "dpif_netdev(pmd-c02/id:74)|DBG|Setting port_forward_flow: port:
> 0x7f63400050b0 flow: 0x7f634000afb0"
> 
> I'm guessing the flow isn't getting added to the port; the insertion
> is currently done when there's an emc hit. I should probably move the
> insertion code to handle_packet_upcall(). As a workaround, can you
> please update the emc insertion probability (ovs-vsctl --no-wait set
> Open_vSwitch . other_config:emc-insert-inv-prob=1) and retry your test
> ?
> 
> Also, please disable normal mode in the bridge (ovs-ofctl del-flows
> br0; and then add ofctl rules).  Let me know if you still see the
> problem, I'll work with you offline.
> 
>>
>> With this proposed patch, what will be the behavior in case there are
>> multiple DP flows for that single openflow rule?
> 
> Right now I'm thinking that the ofctl rule takes precedence since the
> user just wants to forward to another port. If there are multiple DP
> flows, then the first one will act as the default flow.  What do you
> think ?
> 
> Thanks,
> -Harsha
> 
> 
>>
>> Thanks,
>> Eli
>>
>>> flow cache (EMC/SMC) lookup and with a large number of flows it also
>>> results in dpcls lookup due to cache miss. Avoiding cache lookup in
>>> such configurations results in better performance (pps and cpp).
>>>
>>> This patch provides a new interface config parameter - "port-forward",
>>> to avoid datapath cache lookup. When this is enabled, the datapath flow
>>> is saved in the port when there is a cache hit for the initial packet.
>>> For subsequent packets, the flow is readily found in the port structure,
>>> thus avoiding cache and dpcls lookup.
>>>
>>> Example:
>>> $ ovs-vsctl add-port br0 dpdk0 \
>>> -- set Interface dpdk0 other_config:port-forward=true
>>>
>>> A coverage counter has also been added to track packets processed in
>>> port-forward mode.
>>>
>>> $ ovs-appctl coverage/show   | grep datapath_port_forward_packet
>>>
>>> Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna at broadcom.com>