[Top] [All Lists]

Re: [BUG] overflow in net/ipv4/route.c rt_check_expire()

To: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire()
From: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Fri, 1 Apr 2005 17:53:02 +0200
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <424D5D34.4030800@xxxxxxxxxxxxx>
References: <42370997.6010302@xxxxxxxxxxxxx> <20050315103253.590c8bfc.davem@xxxxxxxxxxxxx> <42380EC6.60100@xxxxxxxxxxxxx> <20050316140915.0f6b9528.davem@xxxxxxxxxxxxx> <4239E00C.4080309@xxxxxxxxxxxxx> <20050331221352.13695124.davem@xxxxxxxxxxxxx> <424D5D34.4030800@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx

Eric Dumazet writes:
 > By the way I have an updated patch... surviving very serious loads.

 Did you check for performance changes too? From what I understand 
 we can add new lookup and cache miss in the fast packet path.

 > > Anyways, I think perhaps you should dynamically allocate this lock table.
 > Maybe I should make a static sizing, (replace the 256 constant by something 
 > based on MAX_CPUS) ?

 IMO we should be careful with adding new complexity the route hash.
 Also was this dynamic behavior gc_interval needed to fix the overflow?
 gc_interval is only sort of last resort timer.


<Prev in Thread] Current Thread [Next in Thread>