On 24.06.20 18:42, Eric Dumazet wrote:
>
> Our intention is to get rid of the IPv6 garbage collection, so we need to
> make sure
> we do not rely on it ;)
Hi Eric,
I can't really follow. Did you mean to get rid of the GC or the route cache?
And what is the plan? Separate structures for routes,
On 6/24/20 3:34 AM, Oliver Herms wrote:
> On 24.06.20 00:06, Michal Kubecek wrote:
>> On Tue, Jun 23, 2020 at 01:30:29AM +0200, Oliver Herms wrote:
>>>
>>> I'm encountering the issues due to cache entries that are created by
>>> tnl_update_pmtu. However, I'm going to address that issue in anoth
On 24.06.20 00:06, Michal Kubecek wrote:
> On Tue, Jun 23, 2020 at 01:30:29AM +0200, Oliver Herms wrote:
>>
>> I'm encountering the issues due to cache entries that are created by
>> tnl_update_pmtu. However, I'm going to address that issue in another thread
>> and patch.
>>
>> As entries in the c
On Tue, Jun 23, 2020 at 01:30:29AM +0200, Oliver Herms wrote:
>
> I'm encountering the issues due to cache entries that are created by
> tnl_update_pmtu. However, I'm going to address that issue in another thread
> and patch.
>
> As entries in the cache can be caused on many ways this should be
On Tue, Jun 23, 2020 at 12:46:34AM +0200, Oliver Herms wrote:
> On 22.06.20 23:44, Michal Kubecek wrote:
> > On Mon, Jun 22, 2020 at 10:53:55PM +0200, Oliver Herms wrote:
> >> When fib6_run_gc is called with parameter force=true the spinlock in
> >> /net/ipv6/ip6_fib.c:2310 can lock all CPUs in sof
On 23.06.20 00:55, Eric Dumazet wrote:
>
>
> On 6/22/20 1:53 PM, Oliver Herms wrote:
>> When fib6_run_gc is called with parameter force=true the spinlock in
>> /net/ipv6/ip6_fib.c:2310 can lock all CPUs in softirq when
>> net.ipv6.route.max_size is exceeded (seen this multiple times).
>> One soti
On 6/22/20 1:53 PM, Oliver Herms wrote:
> When fib6_run_gc is called with parameter force=true the spinlock in
> /net/ipv6/ip6_fib.c:2310 can lock all CPUs in softirq when
> net.ipv6.route.max_size is exceeded (seen this multiple times).
> One sotirq/CPU get's the lock. All others spin to get it
On 22.06.20 23:44, Michal Kubecek wrote:
> On Mon, Jun 22, 2020 at 10:53:55PM +0200, Oliver Herms wrote:
>> When fib6_run_gc is called with parameter force=true the spinlock in
>> /net/ipv6/ip6_fib.c:2310 can lock all CPUs in softirq when
>> net.ipv6.route.max_size is exceeded (seen this multiple t
On Mon, Jun 22, 2020 at 10:53:55PM +0200, Oliver Herms wrote:
> When fib6_run_gc is called with parameter force=true the spinlock in
> /net/ipv6/ip6_fib.c:2310 can lock all CPUs in softirq when
> net.ipv6.route.max_size is exceeded (seen this multiple times).
> One sotirq/CPU get's the lock. All ot
When fib6_run_gc is called with parameter force=true the spinlock in
/net/ipv6/ip6_fib.c:2310 can lock all CPUs in softirq when
net.ipv6.route.max_size is exceeded (seen this multiple times).
One sotirq/CPU get's the lock. All others spin to get it. It takes
substantial time until all are done. Eff
10 matches
Mail list logo
