[Top] [All Lists]

Re: 1.03Mpps on e1000 (was: Re: [E1000-devel] Transmission limit)

To: Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx>
Subject: Re: 1.03Mpps on e1000 (was: Re: [E1000-devel] Transmission limit)
From: Scott Feldman <sfeldma@xxxxxxxxx>
Date: Sun, 05 Dec 2004 17:23:25 -0800
Cc: Martin Josefsson <gandalf@xxxxxxxxxxxxxx>, jamal <hadi@xxxxxxxxxx>, Robert Olsson <Robert.Olsson@xxxxxxxxxxx>, P@xxxxxxxxxxxxxx, mellia@xxxxxxxxxxxxxxxxxxxx, e1000-devel@xxxxxxxxxxxxxxxxxxxxx, Jorge Manuel Finochietto <jorge.finochietto@xxxxxxxxx>, Giulio Galante <galante@xxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <>
References: <> <1101824754.1044.126.camel@jzny.localdomain> <> <> <> <> <1101967983.4782.9.camel@localhost.localdomain> <> <> <> <>
Reply-to: sfeldma@xxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Sun, 2004-12-05 at 13:25, Lennert Buytenhek wrote:
> What your patch does is (correct me if I'm wrong):
> - Masking TXDW, effectively preventing it from delivering TXdone ints.
> - Not setting E1000_TXD_CMD_IDE in the TXD command field, which causes
>   the chip to 'ignore the TIDV' register, which is the 'TX Interrupt
>   Delay Value'.  What exactly does this?

A descriptor with IDE, when written back, starts the Tx delay timers
countdown.  Never setting IDE means the Tx delay timers never expire.

> - Not setting the "Report Packet Sent"/"Report Status" bits in the TXD
>   command field.  Is this the equivalent of the TXdone interrupt?
> Just exactly which bit avoids the descriptor writeback?

As the name implies, Report Status (RS) instructs the controller to
indicate the status of the descriptor by doing a write-back (DMA) to the
descriptor memory.  The only status we care about is the "done"
indicator.  By reading TDH (Tx head), we can figure out where hardware
is without reading the status of each descriptor.  Since we don't need
status, we can turn off RS.

> I'm also a bit worried that only freeing packets 1ms later will mess up
> socket accounting and such.  Any ideas on that?

Well the timer solution is less than ideal, and any protocols that are
sensitive to getting Tx resources returned by the driver as quickly as
possible are not going to be happy.  I don't know if 1ms is quick enough.

You could eliminate the timer by doing the cleanup first thing in
xmit_frame, but then you have two problems: 1) you might end up reading
TDH for each send, and that's going to be expensive; 2) calls to
xmit_frame might stop, leaving uncleaned work until xmit_frame is called


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