Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 20 Dec 2022 17:17:57 +0200 (EET)
From:   Julian Anastasov <ja@ssi.bg>
To:     Paolo Abeni <pabeni@redhat.com>
cc:     Jon Maxwell <jmaxwell37@gmail.com>, davem@davemloft.net,
        edumazet@google.com, kuba@kernel.org, yoshfuji@linux-ipv6.org,
        dsahern@kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [net-next] ipv6: fix routing cache overflow for raw sockets
In-Reply-To: <9f145202ca6a59b48d4430ed26a7ab0fe4c5dfaf.camel@redhat.com>
Message-ID: <4ed37beb-7562-f5e4-8d8-4665a653b8c2@ssi.bg>
References: <20221218234801.579114-1-jmaxwell37@gmail.com> <9f145202ca6a59b48d4430ed26a7ab0fe4c5dfaf.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk


	Hello,

On Tue, 20 Dec 2022, Paolo Abeni wrote:

> On Mon, 2022-12-19 at 10:48 +1100, Jon Maxwell wrote:
> > Sending Ipv6 packets in a loop via a raw socket triggers an issue where a 
> > route is cloned by ip6_rt_cache_alloc() for each packet sent. This quickly 
> > consumes the Ipv6 max_size threshold which defaults to 4096 resulting in 
> > these warnings:
> > 
> > [1]   99.187805] dst_alloc: 7728 callbacks suppressed
> > [2] Route cache is full: consider increasing sysctl net.ipv6.route.max_size.
> > .
> > .
> > [300] Route cache is full: consider increasing sysctl net.ipv6.route.max_size.
> 
> If I read correctly, the maximum number of dst that the raw socket can
> use this way is limited by the number of packets it allows via the
> sndbuf limit, right?
> 
> Are other FLOWI_FLAG_KNOWN_NH users affected, too? e.g. nf_dup_ipv6,
> ipvs, seg6?

	For IPVS there is no sndbuf limit. IPVS uses this flag
when receiving packets from world (destined to some local Virtual
IP) and then diverts/redirects the packets (without changing daddr)
to one of its backend servers on the LAN (no RTF_GATEWAY on such routes).
So, for each packet IPVS requests output route with FLOWI_FLAG_KNOWN_NH
flag and then sends the packet to backend server (nexthop) using
this route attached to the skb. Packet rate is usually high. The goal is 
nexthop to be used from the route, not from the IP header. KNOWN_NH 
means "nexthop is provided in route, not in daddr". As for the 
implementation details in ipv6, I can not comment. But all users that
set the flag wants this, to send packet where daddr can be != nexthop.

> @DavidA: why do we need to create RTF_CACHE clones for KNOWN_NH flows?

Regards

--
Julian Anastasov <ja@ssi.bg>