From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 16:14:35 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 08B5797F; Fri, 29 Nov 2013 16:14:35 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1C651F40; Fri, 29 Nov 2013 16:14:34 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rATGESWN039922 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 08:14:32 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5298BD5D.3020203@freebsd.org> Date: Sat, 30 Nov 2013 00:14:21 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: ip_output()/if_output() behaviour References: <52987E27.10503@freebsd.org> <8C291076-5F03-4406-B689-A3185E6DD313@lurchi.franken.de> In-Reply-To: <8C291076-5F03-4406-B689-A3185E6DD313@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org list" , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 16:14:35 -0000 On 11/29/13, 10:06 PM, Michael Tuexen wrote: > On Nov 29, 2013, at 12:44 PM, Julian Elischer wrote: > >> On 11/29/13, 5:42 PM, Michael Tuexen wrote: >>> On Nov 29, 2013, at 3:54 AM, Adrian Chadd wrote: >>> >>>> On 28 November 2013 12:35, Michael Tuexen >>>> wrote: >>>>> Dear all, >>>>> >>>>> I'm investigating a problem and need to understand the behaviour >>>>> of ip_output(). Is it correct that if ip_output() returns an >>>>> non-zero error, the corresponding packet was never sent? >>>>> In the SCTP stack we assume this, but it seems that at least >>>>> the em and the igb driver might return an error from >>>>> igb_mq_start_locked(), for example, but have accepted the packet. >>>> Which error(s) ? >>> ENOBUFS, but does it matter? What is the correct reaction to >>> ip_output() returning an error? The SCTP stack assumes that the >>> packet was not put on the wire. With the current version of the >>> igb driver we are wrong. igb_mq_start() might return an error, >>> even if the packets was enqueued successfully (in case >>> igb_mq_start_locked() fails). >>> >>> But the SCTP stacks assumes in general that if ip_output() returns >>> an error, the packet didn't make it out. >> From my memory it's always been the case that you really have little >> idea if the packet makes it out onto the wire or not. >> In the past it's been the case that an error indicates that it probably DIDN'T make it out, but >> the converse is not true.. NO error is not an indication of success. >> I'm surprised that you could get an error when it was broadcast however.. that is counter >> to the last 30 years of behaviour. > ifnet(9) says: > > if_transmit() > Transmit a packet on an interface or queue it if the interface is > in use. This function will return ENOBUFS if the devices software > and hardware queues are both full. ... > > So I guess returning ENOBUFS when the packet was queued is wrong... I think it is. ENOBUFS means "I couldn't proceed due to no buffers" not "I used up the last one on this operation".