From owner-freebsd-net@FreeBSD.ORG Tue Dec 3 02:06:28 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 85396B28; Tue, 3 Dec 2013 02:06:28 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FECE1C8E; Tue, 3 Dec 2013 02:06:28 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kl14so2202129pab.5 for ; Mon, 02 Dec 2013 18:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=nZzME3o/TJ2qf0NkP981vJJVpjvwnP5B3AfryCKhFTQ=; b=W+qMX4o8sfuaB3nGJFcDp0SbtqO6Jvkkfz2xHhh0zlSqpU693R1CPx4ETS85JwfJuq eiL/XB0VeqJtuhkNRRqTCIkIRxS1dXSDQSSxD13L38nV0hdy0hIl3dEqxu4/nK3Tdaug Cpuv/oSOgS/0sXumIr/n6jGyktII/hnSZ6QdN1YTWeB2RAj8D/YkNi6pL7QhfWtydAJb ZpRt6Edfoy/eMfGYyVL9eP+VwX95yMUkob8WaTybbcGEbZuaysWDWD8+hn6Tw+IUmw1z Swpo0NGp9h+cOyiqHQzIG40bHvY87vUBbhXUjImx3jLgeEHpG0PmWbMUwjl0Xn/VSo1V njpA== X-Received: by 10.68.224.38 with SMTP id qz6mr7547294pbc.156.1386036386327; Mon, 02 Dec 2013 18:06:26 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id sg1sm125857604pbb.16.2013.12.02.18.06.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Dec 2013 18:06:25 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 03 Dec 2013 11:06:18 +0900 From: Yonghyeon PYUN Date: Tue, 3 Dec 2013 11:06:18 +0900 To: Randall Stewart Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c Message-ID: <20131203020618.GB2981@michelle.cdnetworks.com> References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <20131202022338.GA3500@michelle.cdnetworks.com> <1ED6A1C2-6CED-4FDA-9C61-76FBCB2D7452@lakerest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ED6A1C2-6CED-4FDA-9C61-76FBCB2D7452@lakerest.net> User-Agent: Mutt/1.4.2.3i Cc: Jack F Vogel , Michael Tuexen , "freebsd-net@freebsd.org list" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 02:06:28 -0000 On Mon, Dec 02, 2013 at 03:56:59PM -0500, Randall Stewart wrote: > > On Dec 1, 2013, at 9:23 PM, Yonghyeon PYUN wrote: > > > On Fri, Nov 29, 2013 at 06:24:12PM +0100, Michael Tuexen wrote: > >> Dear all, > >> > >> ifnet(9) says regarding 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. > >> > >> The drivers for em, igb and ixgbe might also return an error even > >> in the case the packet was enqueued. The attached patches fix this > >> issue. > > > > How do you know the packet is successfully enqueued but driver > > returns an error? Do non-buf-ring-aware drivers also show the same > > behavior? > > > All of the drivers have traditionally (from what I can tell > and all the ones I have poked at) no matter if they are the new > format (with ring-buf) or the old, would only return an error in > the enqueue if we hit the limit. > > The driver down the road can in theory drop the packet for other > reasons (errors etc) and there is no communication back up to the > upper layers that this occurred. > Hmm, I was under the impression that buf_ring changed old behavior we had in the past. Before introduction of if_transmit, queuing was done in upper layer so returning an error in driver's TX path didn't affect upper layer. With if_transmit, queuing and TX processing would be done in driver. In order to preserve old behavior, buf-ring-aware drivers may have to return ENOBUFS as you said. The compatibility code introduced in if_transmit for legacy drivers shall return ENOBUFS when there is no room in if_snd. This is the reason why I asked whether Michael sees the same behavior on non-buf-ring aware drivers. > > > >> > >> Any comments? > > > > I'm afraid the patch you posted ignores any errors(i.e. > > m_defrag(9), bus_dma(9) etc) happened during TX processing. > > But that is always the case. Most of the time when you send > down to if_transmit() the first time you are going to get > your thread working on those things m_defrag() and bus_dma().. but if > another thread awoke the driver ahead of you all you get is the return > code of the queue into the buffers.. you can't know what is happening on > the other thread that is actually putting the work out. > > This has always been the case. > > This patch I think is *very* much needed on all the ring buffer aware drivers except maybe > Chelsio (since there's is so different it probably does not have this issue). > > I will be applying this to all of Adara's code and I would *strongly* encourage Jack to get this > in to the intel side. > > I will also pull this patch (and fix all the other drivers) in the branch I will be creating > shortly per Adrian's suggestion on the multi-Q qos stuff I was working on.. > > Jack? when can you get this in ?? > > R > > > > > >> > >> Jack: What do you think? Would you prefer to commit the fix if > >> you think it is acceptable? > >> > >> Best regards > >> Michael > > _______________________________________________ > > 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" > > > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > > _______________________________________________ > 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"