[Top] [All Lists]

Re: Queue and SMP locking discussion (was Re: 3c59x.c)

To: Donald Becker <becker@xxxxxxxxx>
Subject: Re: Queue and SMP locking discussion (was Re: 3c59x.c)
From: jamal <hadi@xxxxxxxxxx>
Date: Thu, 30 Mar 2000 15:48:10 -0500 (EST)
Cc: netdev@xxxxxxxxxxx, kuznet@xxxxxxxxxxxxx, andrewm@xxxxxxxxxx
In-reply-to: <Pine.LNX.4.10.10003301359200.2499-100000@vaio.greennet>
Sender: owner-netdev@xxxxxxxxxxx

On Thu, 30 Mar 2000, Donald Becker wrote:

> On Thu, 30 Mar 2000 kuznet@xxxxxxxxxxxxx wrote:
> > > We can now get rid of Space.c, since no current documentation advises 
> > > people
> ..
> > > Not recommended?  But look at what the only guide, the driver conversions,
> > > have as a de facto recommendation -- a horrible spinning waste of time, 
> > > the
> > > cost of which is hidden because it's difficult to measure.
> > 
> > No, Donald. It does not... Well, it was not supposed to tell this at least.
> > Probably, it is badly written.
> Yes.  The de facto guide, the existing SMP changes, are inefficient.
> (And "it's not my fault".  I know I'm sounding like a broken record.)


I am to blame for that -- as is stated in the document disclaimer. Here's
the reasoning:

In my analysis i noted that the "tx timeout" problems under moderate
network loads was _mostly_ because the tx thread was being starved.
(i was blasting a lot of 64 byte packets at the tulip and eepro and
trying to see where they start dying). 
One of the main reasons was that the rx thread interupt was consistently
pre-empting the tx. 
Is the total paralelization you are proposing providing any protection
against such issues? The suggested locks do fix this problem.


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