From owner-freebsd-net@FreeBSD.ORG Fri Dec 6 23:25:05 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 E3BE9BB9; Fri, 6 Dec 2013 23:25:05 +0000 (UTC) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 892E11CB8; Fri, 6 Dec 2013 23:25:05 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id e9so994543qcy.26 for ; Fri, 06 Dec 2013 15:25:04 -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=DY2p0OeQFtAmRu+8iIRt/bYIZT6fpNHMpFhsaXt/uUc=; b=qWk0cLZBCEW0B1R32tyTNUpVChOJNnJ6EccV4cH/tY4QCsE9ZTSNsQkGOLeYJlxAGb R7Lr18F+oEt1VX74E2W05IymVU0cuWlMRfwhwIyOTilXsvvT3SNGwY0vzLDgQqHSDPUD L9iYhi23//2/BjVvj74HohfERHSUxYS8ZAyO65RE9BS9+X/B+aS7tDJJZBe300dJJVeB KYnXsIb0tcdplFU0JFzTMj2ZFs6ucjnN10u8XG1Zc7Ak8Rk1FtaHdUT8MC0I96vxOsT4 Qhv/Bo6h+V5b5kp4adBydJepZxC0603mUSwf9T93hNm17C5g1poS/oXkZpPxj6qrepGY /eYA== MIME-Version: 1.0 X-Received: by 10.224.89.73 with SMTP id d9mr11480031qam.5.1386372304778; Fri, 06 Dec 2013 15:25:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Fri, 6 Dec 2013 15:25:04 -0800 (PST) In-Reply-To: <609C63CD-9332-4EAE-AACE-5B911416DF80@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> Date: Fri, 6 Dec 2013 15:25:04 -0800 X-Google-Sender-Auth: zRzZdbNmCEGXZcUFoZOuhoLJDug Message-ID: Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Adrian Chadd To: Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 06 Dec 2013 23:25:06 -0000 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. -adrian