Received:  by oss.sgi.com id <S42208AbQFYOJI>;
	Sun, 25 Jun 2000 07:09:08 -0700
Received: from iwr1.iwr.uni-heidelberg.de ([129.206.104.40]:3234 "EHLO
        iwr1.iwr.uni-heidelberg.de") by oss.sgi.com with ESMTP
	id <S42183AbQFYOIu>; Sun, 25 Jun 2000 07:08:50 -0700
Received: from kenzo.iwr.uni-heidelberg.de (IDENT:bogdan@kenzo.iwr.uni-heidelberg.de [129.206.120.29])
	by iwr1.iwr.uni-heidelberg.de (8.9.3/8.9.3) with ESMTP id QAA24444;
	Sun, 25 Jun 2000 16:08:19 +0200 (MET DST)
Received: from localhost (bogdan@localhost)
	by kenzo.iwr.uni-heidelberg.de (8.8.7/8.8.7) with ESMTP id QAA25617;
	Sun, 25 Jun 2000 16:08:18 +0200
Date:   Sun, 25 Jun 2000 16:08:18 +0200 (CEST)
From:   Bogdan Costescu <Bogdan.Costescu@IWR.Uni-Heidelberg.De>
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
cc:     Andrew Morton <andrewm@uow.edu.au>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>,
        Andreas Tobler <toa@pop.agri.ch>
Subject: Re: [patch] 3c59x.c for 2.2.17
In-Reply-To: <E136BEN-0002B9-00@the-village.bc.nu>
Message-ID: <Pine.LNX.4.10.10006251540270.25121-100000@kenzo.iwr.uni-heidelberg.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


On Sun, 25 Jun 2000, Alan Cox wrote:

> This is a mess in a lot of Don Becker skeleton base drivers. Its much cleaner 
> if the last ring buffer slot is about to be used and the new alloc fails to 
> simply recycle the buffer and throw the received packet away.
> 
> Several drivers simply require the ring remains full and they are a lot cleaner
> for it.

If I understand it right, you want that the driver never passes one of its
preallocated Rx buffers to the upper levels, so that the Rx ring is always
of size RX_RING_SIZE. On receiving, it tries to allocate a new buffer; if
it's OK it copies the the data to it and sends it up, if it fails it just
ignores that so that the received data (already in the Rx ring buffer) is
discarded.

Don Becker's skeleton has a rx_copybreak scheme which allows this
situation to happen now with a small modification. If you set rx_copybreak
> 1512, it will always allocate a new buffer and memcpy the data to it;
however, in the failing case, it goes through the other branch of 'if', as
the 2 conditions (pkt_len < rx_copybreak and dev_alloc_skb =! NULL) are
AND-ed - a split in two 'if' solves this problem. 
The reason for this AND is that if the new alloc fails, the Rx ring buffer
(with data) is sent up and the re-filling of the Rx ring will (hopefully)
get a new buffer.

So, as I see it, your solution denies the delivery of received data in the
few ring buffers in favor of keeping the already allocated memory. In both
cases, in an OOM situation, the flow of data to upper levels will stop; so
what is the advantage?

Sincerely,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De