From owner-freebsd-net@FreeBSD.ORG Wed Dec 18 23:51:46 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 E56AD29C for ; Wed, 18 Dec 2013 23:51:46 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A3EAC1383 for ; Wed, 18 Dec 2013 23:51:46 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id f11so970073qae.6 for ; Wed, 18 Dec 2013 15:51:45 -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=EFR7OaUHPHlPbWtvJyrCyrGHKW5BLidHBX7iLSZL0mk=; b=Rs5aU9hkEhBPwCQuvC9Hdut7Jlsj8BlibPlUoZQGx4DvuAJGDifWRJKQ3lyF0DwMwy gPC6DPN36KMyoS+YBREagD5/K9z1fnx8QCSFZ/JygJYbA7HsT9dF+FQWCvLgOkI44vq9 bduYTEIiqP/aQOXNrSnNthBuHU/GGuSADoVRayHNSadaQvv3IV2pl8Cs4/3xEZKh1Gky no5+7090iIa279YUljfcQNvARh1KujVPtMJFnA7LrbUIa9+9dwFufoCMJwRbInOu5rpD ay4/Mt1tJRtj9FcgGY5PkOKjlJOq2+PuFUBPceinZGEXO1gwg40462WbaMopZGIQ6cUg FwKQ== MIME-Version: 1.0 X-Received: by 10.224.50.195 with SMTP id a3mr58003667qag.25.1387410705254; Wed, 18 Dec 2013 15:51:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Wed, 18 Dec 2013 15:51:45 -0800 (PST) In-Reply-To: <201312182240.rBIMeTUE006362@hergotha.csail.mit.edu> References: <201312182240.rBIMeTUE006362@hergotha.csail.mit.edu> Date: Wed, 18 Dec 2013 15:51:45 -0800 X-Google-Sender-Auth: j0cOnICd6tDnQbAJ9_vJpDtUyzA Message-ID: Subject: Re: Removing queue length check in ip_output (was Re: buf_ring in HEAD is racy) From: Adrian Chadd To: Garrett Wollman Content-Type: text/plain; charset=ISO-8859-1 Cc: 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: Wed, 18 Dec 2013 23:51:47 -0000 On 18 December 2013 14:40, Garrett Wollman wrote: > In article > , > 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. Right, but this API definitely can't guarantee this as it presently stands anyway. > 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. Ideally we'd pass a list of fragments to the next layer up and such and said layers would treat that list as a "send all or nothing" unit. I have the same issues in the wifi stack with 802.11 fragments. -a