From owner-freebsd-net@FreeBSD.ORG  Wed Dec 18 22:40:32 2013
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 4C627743;
 Wed, 18 Dec 2013 22:40:32 +0000 (UTC)
Received: from hergotha.csail.mit.edu
 (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id 09B711E36;
 Wed, 18 Dec 2013 22:40:31 +0000 (UTC)
Received: from hergotha.csail.mit.edu (localhost [127.0.0.1])
 by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id rBIMeTX3006363;
 Wed, 18 Dec 2013 17:40:29 -0500 (EST)
 (envelope-from wollman@hergotha.csail.mit.edu)
Received: (from wollman@localhost)
 by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id rBIMeTUE006362;
 Wed, 18 Dec 2013 17:40:29 -0500 (EST) (envelope-from wollman)
Date: Wed, 18 Dec 2013 17:40:29 -0500 (EST)
From: Garrett Wollman <wollman@hergotha.csail.mit.edu>
Message-Id: <201312182240.rBIMeTUE006362@hergotha.csail.mit.edu>
To: adrian@freebsd.org
Subject: Re: Removing queue length check in ip_output (was Re: buf_ring in
 HEAD is racy)
In-Reply-To: <CAJ-VmomyPq_2K-MFhb7vt6MM7RBbmn7yaTzUXb7+N7TbW1RmHQ@mail.gmail.com>
Organization: none
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3
 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 18 Dec 2013 17:40:30 -0500 (EST)
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED
 autolearn=disabled version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
 hergotha.csail.mit.edu
Cc: freebsd-net@freebsd.org
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2013 22:40:32 -0000

In article
<CAJ-VmomyPq_2K-MFhb7vt6MM7RBbmn7yaTzUXb7+N7TbW1RmHQ@mail.gmail.com>,
adrian@freebsd.org writes:

>.. it's totally bogus in an if_transmit / SMP world. There's no
>locking and there's no guarantee that there will be headroom in the
>queue between this point and the later call to the if_output() method.

The theory is that when transmitting fragments, it's desirable to have
all-or-nothing transmit behavior with respect to the original packet.
Transmitting incomplete fragmented packets wastes resources on the
local CPU, in the network, and on the remote system, so you should not
do so when it is possible to avoid it.

Ideally, there would be an if_reserve(ifp, N) interface that hands you
a token that you can then pass back N times to if_transmit().  But
it's not clear to me how common or necessary this is, except perhaps
on very busy authoritative DNS servers.  (Are there any other
applications for fragmented UDP these days?)  So it might not be worth
the effort.

-GAWollman