Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jun 2014 10:35:31 -0500
From:      Bryan Venteicher <bryanv@freebsd.org>
To:        Luigi Rizzo <rizzo@iet.unipi.it>
Cc:        jfv@freebsd.org, Bryan Venteicher <bryanv@freebsd.org>, current@freebsd.org, stefanogarzarella@gmail.com
Subject:   Re: BUG: some drivers return ENOBUFS when the mbuf is actually queued
Message-ID:  <CAGaYwLdL50y9iMs5mzy-rqUoFrB05SWHqEctfwJUTwcd3QPCBg@mail.gmail.com>
In-Reply-To: <20140604134945.GA64688@onelab2.iet.unipi.it>
References:  <20140604134945.GA64688@onelab2.iet.unipi.it>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 4, 2014 at 8:49 AM, Luigi Rizzo <rizzo@iet.unipi.it> 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 ?
>
>
No objection for vtnet and vmxnet.


>         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).
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGaYwLdL50y9iMs5mzy-rqUoFrB05SWHqEctfwJUTwcd3QPCBg>