From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 14:06:11 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 219C4204; Fri, 29 Nov 2013 14:06:11 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9EC718A8; Fri, 29 Nov 2013 14:06:10 +0000 (UTC) Received: from [192.168.1.102] (p508F32E7.dip0.t-ipconnect.de [80.143.50.231]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 8F54C1C0C0695; Fri, 29 Nov 2013 15:06:08 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: ip_output()/if_output() behaviour From: Michael Tuexen In-Reply-To: <52987E27.10503@freebsd.org> Date: Fri, 29 Nov 2013 15:06:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8C291076-5F03-4406-B689-A3185E6DD313@lurchi.franken.de> References: <52987E27.10503@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1510) 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 14:06:11 -0000 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: >>=20 >>> On 28 November 2013 12:35, Michael Tuexen >>> wrote: >>>> Dear all, >>>>=20 >>>> 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). >>=20 >> But the SCTP stacks assumes in general that if ip_output() returns >> an error, the packet didn't make it out. > =46rom 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... Any comments? Best regards Michael >=20 >=20 >>=20 >> Best regards >> Michael >>>> Before digging further, I would like to know what the intended >>>> behaviour of ip_output() is. >>>=20 >>> -adrian >>>=20 >> _______________________________________________ >> 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" >>=20 >>=20 >=20 >=20