lkml.org 
[lkml]   [2002]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: NAPI for eepro100
    On Wed, Jun 12, 2002 at 10:25:22PM -0400, Donald Becker wrote:
    > On Wed, 12 Jun 2002, David S. Miller wrote:
    > > From: Jeff Garzik <jgarzik@mandrakesoft.com>
    > > Oh crap, you're right... eepro100 in general does funky stuff with the
    > > way packets are handled, mainly due to the need to issue commands to the
    > > NIC engine instead of the normal per-descriptor owner bit way of doing
    > > things.
    >
    > The eepro100 has a unique design in many different aspects.
    >
    > > The question is, do the descriptor bits have to live right before
    > > the RX packet data buffer or can other schemes be used?
    >
    > With the current driver structure, yes, the descriptor words must be
    > immediately before the packet data. You can use other Rx and Tx
    > structures/modes to avoid this, but they use less efficient memory access.
    > For instance, the current Tx structure allows transmitting a packet with
    > a single PCI burst, rather than multiple transfers.
    Maybe a bit off topic, but we (at my work) are using plenty of eepro100
    cards with both drivers ( e100 and eepro100 )(shipped with dell
    machines, and others).
    We have lot of problem with these card: from link autonegociation to the
    really frequent cmd_timeout.
    We expreienced some freezes, slowdowns, problems with copying from NFS
    to a Firwire disk ( systematic cmd_timeout at about 250 MB).

    Do you have any advice ? should I test eepro100 NAPI driver ?
    I've try to play with ethtool(chang some eepro100 bits , like the
    "sleeping" one ...

    I have quitely the same card at home wich doesn't make any problem ( I
    noticed some cmd_timeout when I changed my hub).
    Is this hub related ? Is there a standart way autonegociation is working
    ( we use mostly cisco switches, are they compliant?).

    We are actually trying to force 10FD or 100FD any new installed card
    because we think this is the best way to avoid performances problem ...

    Thanks for any advice.
    Sam

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:26    [W:3.039 / U:0.204 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site