From owner-freebsd-net@FreeBSD.ORG Thu Dec 19 17:11:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5D54901; Thu, 19 Dec 2013 17:11:08 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 601061452; Thu, 19 Dec 2013 17:11:08 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id k4so5001487qaq.15 for ; Thu, 19 Dec 2013 09:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sJ/YtMJKqvV4Ij1Zp38DmuQatLkgGEh9AIl/Vh17d+Q=; b=GZkePLfXOEunfai6LZPSE2lKf6ARRKssjlzjeTJh/ZVq0mm9NNxky7s4tWbtj4EWFf EG6HH2naNOosJTpgc0DiS7htWN8LIMB63d/fG2bXr+VgPLl+E3Z6UQoRGecq6Y4D5ZMN HetxF7uut0qax0LT25fZSAIiTrSfIgYWUYft4WO24Y+t/396UvG4m4qjkhUFnoeTUSS1 //i0TLSnycvguQQiOWxqK9oIFfrUJxI//uUCYeodaXPSe07fNoo1lh/ipo2W3uCw70uF 8P4vu9of8QmxRLJjCvH6yC8KFwJt00x4bKsADkp0busGPYKxc6Kqv4aXGg8VQSC27+56 pKhw== MIME-Version: 1.0 X-Received: by 10.224.16.204 with SMTP id p12mr5088173qaa.26.1387472962850; Thu, 19 Dec 2013 09:09:22 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Thu, 19 Dec 2013 09:09:22 -0800 (PST) In-Reply-To: <20131219151606.GB71033@FreeBSD.org> References: <20131219151606.GB71033@FreeBSD.org> Date: Thu, 19 Dec 2013 09:09:22 -0800 X-Google-Sender-Auth: -8hrE1D_xdZLhzdWQZNLYO2LaU4 Message-ID: Subject: Re: Removing queue length check in ip_output (was Re: buf_ring in HEAD is racy) From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack F Vogel , Michael Tuexen , Ryan Stone , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 17:11:08 -0000 On 19 December 2013 07:16, Gleb Smirnoff wrote: > On Wed, Dec 18, 2013 at 01:04:43PM -0800, Adrian Chadd wrote: > A> How about we can this check in ip_output(): > A> > A> /* > A> * Verify that we have any chance at all of being able to queue the > A> * packet or packet fragments, unless ALTQ is enabled on the given > A> * interface in which case packetdrop should be done by queueing. > A> */ > A> n = ip_len / mtu + 1; /* how many fragments ? */ > A> if ( > A> #ifdef ALTQ > A> (!ALTQ_IS_ENABLED(&ifp->if_snd)) && > A> #endif /* ALTQ */ > A> (ifp->if_snd.ifq_len + n) >= ifp->if_snd.ifq_maxlen ) { > A> error = ENOBUFS; > A> IPSTAT_INC(ips_odropped); > A> ifp->if_snd.ifq_drops += n; > A> goto bad; > A> } > A> > A> .. it's totally bogus in an if_transmit / SMP world. There's no > A> locking and there's no guarantee that there will be headroom in the > A> queue between this point and the later call to the if_output() method. > > My vote is to remove this. But better leave a comment that we need > an API to send a bunch of packets (or fail them all) via an interface. Yes. I think we need some path to evolve if_transmit to a) transmit multiple frames as a transaction (eg a set of IP or 802.11 fragments) at once, and b) be able to transmit multiple transactions at once. Right now chaining packets together via m_nextpkt can only be used for one or the other. We'd have to set flags in the mbufs to delineate the transaction boundaries and .. ew. -a