On 8/15/24 18:56, Numan Siddique wrote: > On Thu, Aug 15, 2024 at 6:38 AM Dumitru Ceara <[email protected]> wrote: >> >> On 8/15/24 05:02, [email protected] wrote: >>> From: Numan Siddique <[email protected]> >>> >>> 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 completely address the datapath flow >>> explosion issue for IPv6 traffic provided all the logical ports >>> of a logical switch are not configured with port security. >>> >>> [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 >>> Reported-by: Mike Pattrick <[email protected]> >>> Signed-off-by: Numan Siddique <[email protected]> >>> --- >>> >>> v1 -> v2 >>> ------- >>> - Addressed review comments from Ilya. >>> >> >> Hi Numan, >> >> For proxy-arp we still match on unicast ND as far as I can tell. I'm >> not sure if we can remove that part though. Maybe it's something to >> consider as a follow up? > > Hi Dumitru, > Thanks for the review. If a logical switch has a router port with > proxy_arp configured > with IPv6 addresses then the dp flow would match on the ipv6 src/dst fields. > > I've updated the commit message with this limitation. I'm not sure if > we can avoid matching > on unicast ND solicitation for proxy_arp. I need to think about it. > I guess it can be a follow up > if it's possible to address that.
We can still try to limit the impact by matching on the exact unicast eth.dst in case of a unicast ND request, i.e. split the logical flow in two: 1. nd_ns_mcast && ip6.dst=IPv6_mcast && nd.target=IPv6_unicast 2. eth.dst=proxy-mac-address && ipv6.dst=IPv6_unicast && nd.target=IPv6_unicast This will limit the issue to multicast traffic and traffic targeted to the address behind ARP proxy. Datapath flows will have exact match on eth.dst, but only ones going to ARP-proxied addresses will have ip6.dst matches. The ones going between LSPs on the same switch should not be affected by the ip6.dst match. I did not test this, but may be worth exploring. Definitely can be a separate change. Best regards, Ilya Maximets. > > I've submitted v3. Please take a look - > https://patchwork.ozlabs.org/project/ovn/patch/[email protected]/. > I removed the system test and added the test in ovn.at instead so > that the test is reliable. > > Thanks > Numan _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
