From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 17:16:49 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 F318D106566C for ; Mon, 17 Sep 2012 17:16:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C9D908FC12 for ; Mon, 17 Sep 2012 17:16:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3789FB993; Mon, 17 Sep 2012 13:16:49 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Mon, 17 Sep 2012 13:16:45 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209171316.45029.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 17 Sep 2012 13:16:49 -0400 (EDT) Cc: Ryan Stone Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 17:16:50 -0000 On Monday, September 17, 2012 11:49:59 am Ryan Stone wrote: > I know that there have been a lot of discussions about fixing how > packets are handed off to ifnets due to the current methods being > extremely race-prone. Has there been any consensus on how the problem > is going to be solved? > > In my particular case, I've seen an if_bridge interface whose if_snd > queue is full, and once an ifnet reaches that point it will never > transmit anything ever again unless its driver manually calls the > start method somehow. > > As a short-term fix I'm temped to call to if_start in IFQ_HANDOFF_ADJ > even if IFQ_ENQUEUE returns an error, to ensure that the queue will be > drained eventually, but I'm wondering if people are actively working > on longer-term fixes. I think for if_bridge the fix is that it no longer uses if_start. :) For real hardware you will get some sort of TX completion interrupt that will restart the transmit queue. Virtual software-only interfaces such as vlan(4) and if_bridge(4) don't have that luxury though, and the best bet for them is to probably have them use if_transmit instead. vlan(4) and if_bridge(4) are already fixed for that (if_bridge was only fixed a week or so ago in HEAD). -- John Baldwin