From owner-cvs-all  Mon Oct 19 15:09:00 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id PAA25180
          for cvs-all-outgoing; Mon, 19 Oct 1998 15:09:00 -0700 (PDT)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25175;
          Mon, 19 Oct 1998 15:08:59 -0700 (PDT)
          (envelope-from wpaul@FreeBSD.org)
From: Bill Paul <wpaul@FreeBSD.ORG>
Received: (from wpaul@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id PAA07920;
	Mon, 19 Oct 1998 15:08:56 -0700 (PDT)
Date: Mon, 19 Oct 1998 15:08:56 -0700 (PDT)
Message-Id: <199810192208.PAA07920@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject: cvs commit: src/sys/pci if_xl.c if_xlreg.h
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

wpaul       1998/10/19 15:08:56 PDT

  Modified files:
    sys/pci              if_xl.c if_xlreg.h 
  Log:
  Modify the transmit packet queuing strategy a bit to be a little less
  agressive. With the old code, if a descriptor chain was already on its
  way to the chip, xl_start() would try to splice new chains onto the end
  of the current chain by stopping the transmitter, modifying the tail
  pointer of the current chain to point to the head of the new chain, then
  restart the transmitter. The manual says you're allowed to do this and
  it works, but I'm not too keen on it anymore.
  
  The new code waits until the eixsting chain has been sent and then
  queues the next waiting chain in the 'transmit ok' handler.
  
  Performance still looks good one way or the other.
  
  Revision  Changes    Path
  1.14      +21 -19    src/sys/pci/if_xl.c
  1.7       +2 -1      src/sys/pci/if_xlreg.h

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message