Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261231AbUKNB3l (ORCPT ); Sat, 13 Nov 2004 20:29:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261230AbUKNB3l (ORCPT ); Sat, 13 Nov 2004 20:29:41 -0500 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:60351 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id S261231AbUKNB31 (ORCPT ); Sat, 13 Nov 2004 20:29:27 -0500 Message-ID: <4196B4E9.40502@pobox.com> Date: Sat, 13 Nov 2004 20:29:13 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Spatzier CC: linux-kernel@vger.kernel.org, Netdev Subject: Re: [patch 4/10] s390: network driver. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1558 Lines: 44 Thomas Spatzier wrote: > > > >>You should be using netif_carrier_{on,off} properly, and not drop the >>packets. When (if) link comes back, you requeue the packets to hardware >>(or hypervisor or whatever). Your dev->stop() should stop operation and >>clean up anything left in your send/receive {rings | buffers}. >> > > > When we do not drop packets, but call netif_stop_queue the write queues > of all sockets associated to the net device are blocked as soon as they > get full. This causes problems with programs such as the zebra routing > daemon. So we have to keep the netif queue running in order to not block > any programs. This is very, very wrong. You are essentially creating in in-driver /dev/null simulator. This does nothing but chew CPU cycles by having the driver drop packets, rather than allowing the system to work as it should. Queues are DESIGNED to fill up under various conditions. Would not the zebra routing software have the same problems with cable pull under an e1000 or tg3 gigabit NIC? > We also had a look at some other drivers and the common behaviour seems to > be that packets are lost if the network cable is pulled out. Which drivers, specifically, are these? The most popular drivers -- e1000, tg3, etc. -- do not do this, for very good reasons. Jeff - 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/