From owner-freebsd-net@FreeBSD.ORG Sun Dec 8 12:03:26 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 F1DBEA34; Sun, 8 Dec 2013 12:03:25 +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 7CC7A1EA8; Sun, 8 Dec 2013 12:03:25 +0000 (UTC) Received: from [192.168.1.200] (p508F285F.dip0.t-ipconnect.de [80.143.40.95]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7ACED1C0C069A; Sun, 8 Dec 2013 13:03:22 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Michael Tuexen In-Reply-To: Date: Sun, 8 Dec 2013 13:03:21 +0100 Content-Transfer-Encoding: 7bit Message-Id: <9E163DC1-D647-4E19-BE23-44E5DFE2F284@lurchi.franken.de> References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <20131202022338.GA3500@michelle.cdnetworks.com> <20131203021658.GC2981@michelle.cdnetworks.com> <20131205223711.GB55638@funkthat.com> <3576B69E-E943-46E0-83E5-0B2194A44ED0@lurchi.franken.de> <20131206202012.GG55638@funkthat.com> <609C63CD-9332-4EAE-AACE-5B911416DF80@lurchi.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1510) Cc: Yong-Hyeon Pyun , Jack F Vogel , John-Mark Gurney , "freebsd-net@freebsd.org list" 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: Sun, 08 Dec 2013 12:03:26 -0000 On Dec 7, 2013, at 12:25 AM, Adrian Chadd wrote: > On 6 December 2013 13:10, Michael Tuexen > wrote: > >> Well, this is what happens: >> The sender takes a packet from the send-queue, calls ip-output. Since >> it returns an error, we don't move it to the sent-queue, but leave >> it in the send queue (assuming it doesn't went on the wire). >> However, the driver puts it on the wire, it makes it to the peer, >> the peer sends SACK, and we receive the SACK. Since the packet is >> not on the sent queue, we don't realize that it is acked. Receiving >> a SACK is a trigger for sending a packet. So we take the next one >> from the send-queue (the one from the beginning), and send it again. >> So it is a wire speed ping pong... >> So in case the lower layer tells us that there was a problem in >> sending the packet, we >> * don't consider it sent >> * wait for the next normal protocol trigger for send another packet. >> This sounds OK to me... >> >> That is why I need to know what an error from ip_output() means. >> If I can't conclude that the provided packet was dropped, I can just >> consider it sent and don't try to do any optimisation. > > We're heading down the right path. > > I'm increasingly believing that ignoring the return value is the > correct thing to do. You mean ignoring the return value transport layer? Why not provide a return code which can be used? Returning a value which needs to be ignored doesn't make a lot of sense to me... I think if_transmit() should only return an error if there was a problem with the provided packet, not with some packet, probably a different one. Can you point me to a consumer of the return code of if_transmit(), which can benefit from the logic you described? Best regards Michael > > > -adrian >