From owner-freebsd-current@FreeBSD.ORG Wed Jun 4 14:24:38 2014 Return-Path: Delivered-To: current@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 EF65EDA3; Wed, 4 Jun 2014 14:24:38 +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 DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A8842882; Wed, 4 Jun 2014 14:24:38 +0000 (UTC) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EFC311C104EC4; Wed, 4 Jun 2014 16:24:35 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: BUG: some drivers return ENOBUFS when the mbuf is actually queued From: Michael Tuexen In-Reply-To: <20140604134945.GA64688@onelab2.iet.unipi.it> Date: Wed, 4 Jun 2014 16:24:34 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20140604134945.GA64688@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1878.2) Cc: jfv@freebsd.org, bryanv@freebsd.org, current@freebsd.org, stefanogarzarella@gmail.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 14:24:39 -0000 On 04 Jun 2014, at 15:49, Luigi Rizzo wrote: > Hi, > if I read correctly the code, there are a few network device drivers > (igb, ixgbe, i40e, vtnet, vmxnet) where ifp->if_transmit(ifp, m) > can return ENOBUFS even when 'm' has _not_ been dropped: > > e1000/if_igb.c :: igb_mq_start() > can return ENOBUFS from igb_xmit() > > ixgbe/ixgbe_main.c :: ixgbe_mq_start_locked() > can return ENOBUFS from ixgbe_xmit() > (similar for i40) > > virtio/network/if_vtnet.c :: vtnet_txq_mq_start > can return ENOBUFS if virtqueue_full() > > In all these cases, the error comes from a later attempt to transfer > mbufs from the buf_ring to the NIC ring. > > All drivers using if_transmit() seem correct, as well as a bunch > of others (cxgbe, sfxge, mxge ...) that reassign if_transmit and I > checked for correctness. > > I think that when the current buffer has been queued, returning > ENOBUFS is extremely confusing and should not be done. > > I would also argue that the return from ifp->if_transmit(ifp, m) > should only tell what happened to 'm', not other things > such as the status of the queue. > > Any objections if i fix the above drivers ? I started a discussion on this last december on net@. The subject of the thread was 'A small fix for if_em.c, if_igb.c, if_ixgbe.c'. I think Adrian wanted to put the latest version of the patch in but possibly never did... See the last mail from Jan 5th. Best regards Michael > > cheers > luigi > > (For those curious: i found this issue when using emulated > netmap mode on top of a standard driver. The netmap emulation > code assumes that ENOBUFS indicates that the driver has > m_free()'d the mbuf, same as it happens on linux, and the > bug was causing panics in my system). > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >