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

Tue Apr 27 15:57:48 UTC 2021

On Tue, Apr 27, 2021 at 6:42 PM Eli Britstein <elibr at nvidia.com> wrote:
>
>
> On 4/27/2021 2:45 PM, Sriharsha Basavapatna wrote:
> > On Tue, Apr 27, 2021 at 4:26 PM Ilya Maximets <i.maximets at ovn.org> wrote:
> >> 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.
> > That's right. Allow the first packet to go through match, upcall,
> > dp/cache insertion etc. For subsequent packets avoid lookup.
> >
> >>   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.
> > If I add a constraint to check that there is only one action and it's
> > an OUTPUT action (i.e don't enable port-forward mode if the DP flow
> > contains other actions like modify), like it is done in your patch,
> > that should handle this issue ?
> >
> > Thanks,
> > -Harsha
> >> 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 ?
>
> Indeed this is what the user asked for, but it doesn't fit OVS.
>
> OVS always matches on those fields, so there are multiple DP flows. If
> only the first one is hit, it breaks functionality. Though traffic
> passes, other flows will age out as their counters will be wrong.

No, other flows won't age out since DP flows won't even get created
for those flows as there will be a hit in dfc_processing() based on
the in_port and the first DP flow would be used (as
p->port_forward_flow is already set; see code below).  The packet/byte
counts for the traffic from those other flows would be counted in the
DP flow corresponding to the first flow (and you would see only one DP
flow in dpctl/dump-flows). I've verified this by running IPv4 and IPv6
traffic parallelly. So it works fine as long as the only ofctl rule
that's specified is for port forwarding (in_port=1, output=2).

            p = pmd_send_port_cache_lookup(pmd, port_no);
            if (p->port_forward_flow) {
                dp_netdev_queue_batches(packet, p->port_forward_flow,
                                        tcp_flags, batches, n_batches);
>
> Another interesting case to test is what if there are OpenFlow rules to
> do different things with the "forced" matches, for example drop IPv6,
> and forward all the rest.
>
> Will this mode take effect in this case too? If so, it will break also
> the desired user configuration, if the first "default" flow is IPv4 one,
> and IPv6 will pass.

Yes, this test case could be a problem; so the requirement is there's
only one ofctl rule to just forward all packets (any dl_type) from the
given in_port to another port.

Thanks,
-Harsha
>
> Am I wrong?
>
> >>>
> >>> 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>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.