Mitigation and autonegotiation

[Andrew Morton]

Bogdan Costescu wrote:
> 
> On Thu, 20 Apr 2000, Andrew Morton wrote:
> 
> > Replying to myself again.  Sigh.
> >
> > I've worked this one out.  If we clear TxIntrUploaded in the first leg
> > of the 'if' then we'll only take an interrpt when _all_ packets have
> > been uploaded, and there will be a tx gap while the CPU restarts the
> > netif layer and starts to queue up more packets.  SO the original code
> > is better: it'll generate an interrupt on the last-but-oneth queued
> > packet, thus providing some interleaving. A little optimisation.
> 
> And also by "skipping" some interrupts, you increase the time between 2
> Tx generated interrupts, which is bad for applications which fight for
> lowest possible latency (M-VIA, etc.) Actually, I found good Mr. Becker's
> ideea of enclosing TxIntrUploaded with a #ifdef interrupt_mitigation in
> 0.99L; this way, you only start to skip interrupts if you really want to
> (and define this).

I don't understand this one.  Provided the netif layer can respond to
the n-minus-oneth interrupt within a packet tx time, there will be no
interruption to the Tx stream.

What advantage is there to generating extra interrupts?

The only advantage I can see is that the tx ring will always be pretty
much full, rather than filling right up in a big burst then emptying
down to a single packet.  If your system is experiencing large interrupt
blockages then you will see better tx performance because the NIC
hardware has more to be going on with.

Linux occasionally blocks interrupts for 3 milliseconds in the console
code, and frequently blocks them for ~500 microseconds in the IDE code
(unless you use 'hdparm -u'), so maybe this is the difference.

> > > > Yes, I'm running full duplex. However, I had to modify both 0.99L and your
> > > > driver to get this: set 3c905C as IS_CYCLONE|HAS_NWAY and then comment out
> > > > one line in vortex_probe1:
> >
> > I sent this suggestion through to a 905C owner who was having big
> > autoneg problems.  His reply this morning stated with "Cool!".  Looks
> > good.
> 
> I tried again today and I found out that commenting the line in
> vortex_probe1() was not necessary; I don't remember what made me do it...
> The full duplex capability is correctly identified based on the MII
> registers in vortex_open() if dev->if_port == XCVR_NWAY.
> So, only adding HAS_NWAY to 3c905C capabilities should do it.

That was the conclusion I'd come to.  Thanks.

Still two problems remain with this driver:

1: Why the 3c575 (cardbus) cards usually come up receiving but not
transmitting (another person is experiencing this exact thing with the
574_cs and 589_cs drivers also).

2: The "sleepy NIC" problem.

You don't have a laptop, do you Bogdan? :-)

-- 
-akpm-
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-vortex-bug-request@beowulf.org