From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Greear Subject: Re: ARP table question Date: Mon, 17 Nov 2008 17:23:53 -0800 Message-ID: <49221929.7060504@candelatech.com> References: <491B1841.9050404@candelatech.com> <491B31EB.4050304@candelatech.com> <491B5452.6020709@candelatech.com> <20081116.191628.135824721.davem@davemloft.net> <4921B521.1010305@candelatech.com> <49220D75.1070803@candelatech.com> <4922119E.6030601@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, Patrick McHardy To: Rick Jones Return-path: Received: from mail.candelatech.com ([208.74.158.172]:59542 "EHLO ns3.lanforge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751738AbYKRBX7 (ORCPT ); Mon, 17 Nov 2008 20:23:59 -0500 In-Reply-To: <4922119E.6030601@hp.com> Sender: netdev-owner@vger.kernel.org List-ID: Rick Jones wrote: >> +static unsigned long neigh_rand_retry(struct neighbour* neigh) { >> + if (neigh->parms->retrans_rand_backoff) { >> + return net_random() % neigh->parms->retrans_rand_backoff; >> + } >> + return 0; >> +} >> + >> /* Called when a timer expires for a neighbour entry. */ > > I thought that mod was something we tried to avoid? Could you instead > use something that isn't random but perhaps varies among all the > requests? Say some of the low-order bits of the IP being resolved? This is only called when we are going to retransmit an ARP, which shouldn't be in any sort of hot path, so I figured MOD was fine. The net_random is a very cheap method (last I checked), as well. So, I think that part is OK as it is, but I'm open to persuasion :) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com