On 8/16/24 12:04, Numan Siddique wrote: > > > On Fri, Aug 16, 2024, 5:38 AM Dumitru Ceara <dce...@redhat.com > <mailto:dce...@redhat.com>> wrote: > > On 8/15/24 18:52, num...@ovn.org <mailto:num...@ovn.org> wrote: > > From: Numan Siddique <num...@ovn.org <mailto:num...@ovn.org>> > > > > IPv6 ND Solicitation (NS) responder logical flows match on ip6.dst > > field. These flows when translated to datapath flows also match on > > ip6.dst, which means a separate datapath flow per destination IP > > address. This may cause significant performance issues in some > > setups (particularly ovs-dpdk telco deployments). > > > > This patch addresses this issue by matching on eth.mcast6 so that > > datapath flows for normal IPv6 traffic doesn't have to match on > > ip6.dst. IPv6 NS packets are generally multicast. A new logical > > match "nd_ns_mcast" is added for this purpose. > > > > After this patch, We no longer respond to IPv6 NS unicast packets. > > Let the target reply to it, so that the sender has the ability to > > monitor the targe liveness via the unicast ND solicitations. > > This behavior now matches the IPv4 ARP responder flows. Note that > > after the commit [1] which was recently added we now only respond > > to IPv4 ARP broadcast packets. > > > > A recent patch [2] from Ilya partially addressed the same datapath > > flow explosion issue by matching on eth.mcast6 for MLD packets. > > With this patch, we now address the datapath flow explosion issue > > for IPv6 traffic provided 2 conditions are met: > > a. All the logical ports of a logical switch are not configured > > with port security. > > b. The logical switch port of type router if configured > > with "arp_proxy" option doesn't include any IPv6 address(es). > > > > [1] - c48ed1736a58 ("Do not reply on unicast arps for IPv4 targets.") > > [2] - 43c34f2e6676 ("logical-fields: Add missing multicast matches > for MLD and IGMP.") > > > > Note: Documentation for 'eth.mcastv6' and 'ip6.mcast' predicates were > > missing from ovn-sb.xml and this patch adds it. > > > > Reported-at: https://issues.redhat.com/browse/FDP-728 > <https://issues.redhat.com/browse/FDP-728> > > Reported-by: Mike Pattrick <m...@redhat.com <mailto:m...@redhat.com>> > > Signed-off-by: Numan Siddique <num...@ovn.org <mailto:num...@ovn.org>> > > --- > > > > v2 -> v3 > > ------- > > The CI failures look unrelated to the change to me: > > https://github.com/ovsrobot/ovn/actions/runs/10407451042/job/28823295402 > <https://github.com/ovsrobot/ovn/actions/runs/10407451042/job/28823295402> > https://github.com/ovsrobot/ovn/actions/runs/10407451041/job/28822927349 > <https://github.com/ovsrobot/ovn/actions/runs/10407451041/job/28822927349> > > Recheck-request: github-robot > > > FYI - The CI has passed on my GitHub repo > - > https://github.com/numansiddique/ovn/commit/27e40a0ed759c0e535c1d13e319082137a24e52f > > <https://github.com/numansiddique/ovn/commit/27e40a0ed759c0e535c1d13e319082137a24e52f> >
Yes, it passes in my fork too. We do probably need to investigate those CI flakes at some point in the future and figure out if the test is broken or if there's an actual issue hiding somewhere. Worst case we could mark the tests as "unstable" so they get re-run in CI. Regards, Dumitru _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
