From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 11:44:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52C2088B; Fri, 29 Nov 2013 11:44:58 +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 08B4010B1; Fri, 29 Nov 2013 11:44:57 +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 rATBikv0039170 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 03:44:49 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52987E27.10503@freebsd.org> Date: Fri, 29 Nov 2013 19:44:39 +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 , Adrian Chadd Subject: Re: ip_output()/if_output() behaviour References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org list" 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 11:44:58 -0000 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. > > Best regards > Michael >>> Before digging further, I would like to know what the intended >>> behaviour of ip_output() is. >> >> -adrian >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >