From owner-freebsd-net@FreeBSD.ORG Sun Jan 5 08:44:19 2014 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 155B0338; Sun, 5 Jan 2014 08:44:19 +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 966AD1D46; Sun, 5 Jan 2014 08:44:18 +0000 (UTC) Received: from [192.168.1.103] (p508F311C.dip0.t-ipconnect.de [80.143.49.28]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3E9EB1C0C0692; Sun, 5 Jan 2014 09:44:15 +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, 5 Jan 2014 09:44:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <201312131326.28952.jhb@freebsd.org> <201312131717.10863.jhb@freebsd.org> <0BC9D25E-639A-4305-A51A-222AE645152C@lurchi.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1510) Cc: Yong-Hyeon Pyun , John Baldwin , FreeBSD Net , John-Mark Gurney , Jack Vogel , Jack F Vogel 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, 05 Jan 2014 08:44:19 -0000 On Jan 4, 2014, at 11:45 PM, Adrian Chadd wrote: > hi, >=20 > Happy New Year all. >=20 > If noone objects, I'm going to commit Michael's patch to -HEAD in the > next couple of days, with some extra comments explaining why things > are the way they are. Hi Adrian, just use the last version of the patch, the one from December 6th... Best regards Michael >=20 > We can then flesh out the comments and API documentation about this = stuff. >=20 > Thanks! >=20 >=20 >=20 > -a >=20 >=20 > On 16 December 2013 19:25, Adrian Chadd wrote: >> On 16 December 2013 13:04, Michael Tuexen >> wrote: >>> On Dec 16, 2013, at 9:15 PM, Adrian Chadd = wrote: >>>=20 >>>> On 16 December 2013 12:06, Michael Tuexen >>>> wrote: >>>>=20 >>>>>> i agree. if_transmit() should return 0 only if: >>>>>>=20 >>>>>> * the driver queued it internally and intends to try transmitting = it later; >>>>>> * the driver directly dispatched the frame to the hardware. >>>>>>=20 >>>>>> If it failed to do either of the above, it should return an = error. >>>>>>=20 >>>>>> How's that sound? >>>>> That sounds good. However, The transport layer is interested in = the case >>>>> where if_transmit() returns a non-zero value. >>>>> Does your statement imply: >>>>> if_transmit() returns a non-zero value only if the packet will not >>>>> make it on the wire (for example, it failed to queue it). >>>>=20 >>>> If there's a queuing layer in the middle then we can't know that = for >>>> certain. If the driver can't transmit the frame (eg it fails = because >>>> of collisions, for example) then again, we can't know that for >>>> certain. >>>>=20 >>>> What we can only know is that it was either queued and may or may = not >>>> make it on the wire, or it wasn't queued/transmitted and it = definitely >>>> _won't_ make it on the wire. >>> Correct. And I'm only interested in the "it wasn't = queued/transmitted >>> and it definitely _won't_ make it on the wire." part. >>> So I would need something like >>>=20 >>> if_transmit() returns an error only if it wasn't queued/transmitted >>> and it definitely _won't_ make it on the wire. >>>=20 >>> Acceptable for you? >>=20 >> Sounds like the same thing to me, so yes. :) >>=20 >>=20 >>=20 >> -a >=20