Re: [net PATCH 2/2] ipv4: Drop suffix update from resize code

2016-12-05 Thread Robert Shearman
On 05/12/16 17:28, David Miller wrote: From: Robert Shearman Date: Mon, 5 Dec 2016 15:05:18 + On 01/12/16 12:27, Alexander Duyck wrote: It has been reported that update_suffix can be expensive when it is called on a large node in which most of the suffix lengths are the same. The time re

Re: [net PATCH 2/2] ipv4: Drop suffix update from resize code

2016-12-05 Thread Duyck, Alexander H
On Mon, 2016-12-05 at 12:28 -0500, David Miller wrote: > From: Robert Shearman > Date: Mon, 5 Dec 2016 15:05:18 + > > > > > On 01/12/16 12:27, Alexander Duyck wrote: > > > > > > It has been reported that update_suffix can be expensive when it is > > > called > > > on a large node in which m

Re: [net PATCH 2/2] ipv4: Drop suffix update from resize code

2016-12-05 Thread David Miller
From: Robert Shearman Date: Mon, 5 Dec 2016 15:05:18 + > On 01/12/16 12:27, Alexander Duyck wrote: >> It has been reported that update_suffix can be expensive when it is >> called >> on a large node in which most of the suffix lengths are the same. The >> time >> required to add 200K entries

Re: [net PATCH 2/2] ipv4: Drop suffix update from resize code

2016-12-05 Thread Robert Shearman
On 01/12/16 12:27, Alexander Duyck wrote: It has been reported that update_suffix can be expensive when it is called on a large node in which most of the suffix lengths are the same. The time required to add 200K entries had increased from around 3 seconds to almost 49 seconds. In order to addr

[net PATCH 2/2] ipv4: Drop suffix update from resize code

2016-12-01 Thread Alexander Duyck
It has been reported that update_suffix can be expensive when it is called on a large node in which most of the suffix lengths are the same. The time required to add 200K entries had increased from around 3 seconds to almost 49 seconds. In order to address this we need to move the code for updati