linux-mips
[Top] [All Lists]

Re: [PATCH 4/4] Staging: Octeon: Free transmit SKBs in a timely manner.

To: David Daney <ddaney@caviumnetworks.com>
Subject: Re: [PATCH 4/4] Staging: Octeon: Free transmit SKBs in a timely manner.
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 15 Feb 2010 22:11:11 +0100
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, netdev@vger.kernel.org, gregkh@suse.de
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=Xq6Xyg+3Idj776ASAQiLwS8t/hOE18xj9DvxZkaePpk=; b=Fi6Vg6BL99KT8UyszhhugTNyjAeCg8t0KTIXpporu3pK35vI81dyh4+CZVmGIBxEwP zGBSg56m//Lut4HQtR09kG35bLmYVW4phApVBqYWA6sH00V419NKcTG3tPXeEL/sytHv domIChspIoTKUnPTnzQ0MgSx559Eay+K+7Z8Q=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=R2vBYePmaC61YWJLDdqwCccokQt911TYPcyQpAB8bn5TslEoLgJBA//LdGwyRazV3D lulv7EZu54J4wb8OvEjDn+dzq/3+2zoY+xehxkkuVNUFKt+WnpPWLg+M0DSAJH2IxB8Y vTmmCGd/kV4mubg3zmBIVW2l53gOI+2DWdYUQ=
In-reply-to: <4B79B15F.7030506@caviumnetworks.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4B79AAA6.60005@caviumnetworks.com> <1266264799-3510-4-git-send-email-ddaney@caviumnetworks.com> <1266265673.2859.5.camel@edumazet-laptop> <4B79B15F.7030506@caviumnetworks.com>
Sender: linux-mips-bounce@linux-mips.org
Le lundi 15 février 2010 à 12:41 -0800, David Daney a écrit :
> On 02/15/2010 12:27 PM, Eric Dumazet wrote:
> > Le lundi 15 février 2010 à 12:13 -0800, David Daney a écrit :
> >> If we wait for the once-per-second cleanup to free transmit SKBs,
> >> sockets with small transmit buffer sizes might spend most of their
> >> time blocked waiting for the cleanup.
> >>
> >> Normally we do a cleanup for each transmitted packet.  We add a
> >> watchdog type timer so that we also schedule a timeout for 150uS after
> >> a packet is transmitted.  The watchdog is reset for each transmitted
> >> packet, so for high packet rates, it never expires.  At these high
> >> rates, the cleanups are done for each packet so the extra watchdog
> >> initiated cleanups are not needed.
> >
> > s/needed/fired/
> >
> 
> or perhaps s/are not needed/are neither needed nor fired/
> 
> > Hmm, but re-arming a timer for each transmited packet must have a cost ?
> >
> 
> The cost is fairly low (less than 10 processor clock cycles).  We didn't 
> add this for amusement, people actually do things like only send UDP 
> packets from userspace.  Since we can fill the transmit queue faster 
> than it is emptied, the socket transmit buffer is quickly consumed.  If 
> we don't free the SKBs in short order, the transmitting process get to 
> take a long sleep (until our previous once per second clean up task was 
> run).

I understand this, but traditionaly, NIC drivers dont use a timer, but a
'TX complete' interrupt, that usually fires a few us after packet
submission on Gigabit speed.

A fast program could try to send X small udp packets in less than 150
us, X being greater than the size of your TX ring.

So your patch makes the window smaller, but it still is there (at
physical layer, we'll see a burst of packets, a ~100us delay, then a
second burst)




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