From owner-freebsd-net@FreeBSD.ORG Tue Dec 25 02:32:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFC27E9B; Tue, 25 Dec 2012 02:32:08 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [IPv6:2001:470:c004::5]) by mx1.freebsd.org (Postfix) with ESMTP id B0F4C8FC0C; Tue, 25 Dec 2012 02:32:08 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.5/8.14.5) with ESMTP id qBP1x63t099398; Mon, 24 Dec 2012 19:59:06 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201212250159.qBP1x63t099398@mail.karels.net> To: Adrian Chadd From: Mike Karels Subject: Re: 'no buffer space available' after switch goes down on freeBSD 7.3 In-reply-to: Your message of Mon, 24 Dec 2012 17:45:47 -0800. Date: Mon, 24 Dec 2012 19:59:06 -0600 Cc: freebsd-net , Ryan Stone , Tsaregorodtsev Denis X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mike@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 02:32:09 -0000 > On 24 December 2012 17:01, Ryan Stone wrote: > > I don't believe that this is fixed in later versions of the driver. The > > problem is that when the interface loses link the transmit queue can fill > > up. Once that happens the driver never gets any more calls from the network > > stack to make it send packets. Pinging the interface fixes it because the > > driver processes rx.and tx from the same context, so when it receives a > > packet it starts transmitting again. > > > > The patch that I sent fixes the problem by forcing the driver to process > > the tx queue when ever links goes from down to up. > This is a cute fix, and I've noticed similar issues in net80211. > In net80211, the stack currently calls if_start() to re-attempt frame > transmission during a VAP state transition to RUN. > This has similar issues (ie, it assumes that if_start() DTRT; it > assumes OACTIVE has been cleared, etc.) > I think we may need another if_* method which specifically attempts to > service the TX queue again; versus just waiting for if_transmit() to > make some progress. In my opinion, it is wrong of the drivers to queue packets while link is down. The packets are delayed indefinitely, and are useless at best. In my company's product (McAfee firewall), we had problems with state-sharing packets that were way out of date in a cluster. We changed the drivers to empty the queue and discard subsequent packets when link was down. No special change is needed to restart: the next time a packet is transmitted after link comes up, that packet is sent. Our change is not necessarily done the way I'd do it for FreeBSD, but it minimizes changes. Patch available on request. Mike