From owner-freebsd-net@FreeBSD.ORG Fri Dec 13 21:51:20 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 45576F8B; Fri, 13 Dec 2013 21:51:20 +0000 (UTC) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D21801157; Fri, 13 Dec 2013 21:51:19 +0000 (UTC) Received: by mail-qe0-f54.google.com with SMTP id cy11so2084560qeb.41 for ; Fri, 13 Dec 2013 13:51:19 -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=tXs7giMQt1djVpqLahZ8x6pOU8qkU2TmqwC0AsB4zYA=; b=0mzruVXqdOaqoHAMMkJAExZlfDBDn/CTde3eC/OLRnOEVUX7G9CJA8Li0vG4es2X9e Qz1M8TxZRJFMFuAxFl99GFjh4oVqQSGCYiU2O5bNKxkNHQNVJ224ulpxORUECtSOKnua S6bsuoGSps6hiRGvnR/HrsULS5KxEtJqJiCeuzpArOZE0stalAvcmuLdfUk/NsUpz0sq T8I9ZNKJWp/x8pPJ5nFqlOSWgRfTwYegm6NtXfWVD5xrmdPBCUUsUiiY2a4AVaG3LJD+ POr5yZ+1coYK/AFEFRhV0tWnq8X/0eayJhifUzCZ2zpwO3f3BECW9Mq6xUCCP3kIYaFf 1cmg== MIME-Version: 1.0 X-Received: by 10.224.24.131 with SMTP id v3mr8878132qab.48.1386971478892; Fri, 13 Dec 2013 13:51:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Fri, 13 Dec 2013 13:51:18 -0800 (PST) In-Reply-To: <201312131326.28952.jhb@freebsd.org> References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <201312131326.28952.jhb@freebsd.org> Date: Fri, 13 Dec 2013 13:51:18 -0800 X-Google-Sender-Auth: wauKSqR0z6ROP6rHujrBPWd2_Q0 Message-ID: Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Yong-Hyeon Pyun , FreeBSD Net , John-Mark Gurney , Jack F Vogel , Michael Tuexen 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, 13 Dec 2013 21:51:20 -0000 On 13 December 2013 10:26, John Baldwin wrote: > On Monday, December 09, 2013 2:37:08 pm Adrian Chadd wrote: >> Jack / John - thoughts? > > Note that if_start has always worked the way if_transmit would work with the > err = 0 change. All the other drivers in the tree are already giving you an > error if an earlier packet in the IFQ fails to transmit, and it's been that > way for decades. If you decide to make if_transmit precise (only return an > error if the specific packet fails), the corresponding change for if_start() > drivers would be to never return an error ever. Right. If we want some kind of sane network behaviour moving forward we .. well, we have to define it as being sane. :-) IMHO if_start()'s API should've been: * queue something to the ifnet queue - fail it we can't queue it * call if_start() to start trying to transmit something - a failure is not that the queued frame failed, but the driver is unable to dequeue frames. Anyone using if_start() failing as "the frame i just queued failed to transmit" is broken and well, we should just replace it with if_transmit(). > It's not clear to me what the impact of that would be. However, the current > patch to return 0 in the drbr_putback case would at least restore things to > the previous status quo from the past few decades for both if_start() and > if_transmit() drivers. I believe the most correct return behaviour from if_transmit() is "the frame was successfully queued to the driver; it's now up to the driver to eventually send the frame." If the driver does direct dispatch then it'll error out if it couldn't queue the frame to the hardware TX descriptor ring/queue/blah. If the driver does its own queuing then it's up to the driver itself to fail on the hardware transmit function and then retry it when appropriate. It shouldn't be dropping frames during normal transmit unless there's some kind of policy in place to do so - and yes, this is a separate discussion to have with andre and rrs. -adrian