netdev
[Top] [All Lists]

Re: tg3 support broken on PPC, a workaround

To: "David S.Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: tg3 support broken on PPC, a workaround
From: "Michael Chan" <mchan@xxxxxxxxxxxx>
Date: Tue, 10 May 2005 13:49:39 -0700
Cc: mperaya@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050510.142319.70222971.davem@xxxxxxxxxxxxx>
References: <20050510.121214.39158393.davem@xxxxxxxxxxxxx> <20050510.132642.85686818.davem@xxxxxxxxxxxxx> <1115756070.8570.76.camel@rh4> <20050510.142319.70222971.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Tue, 2005-05-10 at 14:23 -0700, David S.Miller wrote:
> From: "Michael Chan" <mchan@xxxxxxxxxxxx>
> Subject: Re: tg3 support broken on PPC, a workaround
> Date: Tue, 10 May 2005 13:14:30 -0700
> 
> > I don't think target-initiated disconnects will waste PCI bandwidth
> > compared to master-initiated terminations. In both cases, you see the
> > same DMA bursts across the bus, only the termination of each burst is
> > different.
> 
> I think it does Michael.  Performance on sparc64 went non-trivially up
> when I added the read/write boundary settings initially long ago.
> 
> You have the extra phase where the tg3 tries to start the DMA of the
> next cacheline, and that is where unnecessary time is lost.  I think
> it's about 2 clocks you lose if the PCI controller disconnects instead
> of tg3.
> 
> Tigon3 will drive the data of the next cacheline for 1 cycle and this
> is when the PCI controller will disconnect.  Tigon3 will drop the data
> and respond to the disconnect sometime in the next cycle or so.
> 

You're right. This is Disconnect Without Data and it does cost a few
clock cycles compared to Disconnect With Data or master initiated
termination.



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