Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Dec 2013 09:09:22 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Gleb Smirnoff <glebius@freebsd.org>
Cc:        Jack F Vogel <jfv@freebsd.org>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, Ryan Stone <rysto32@gmail.com>, freebsd-net <freebsd-net@freebsd.org>
Subject:   Re: Removing queue length check in ip_output (was Re: buf_ring in HEAD is racy)
Message-ID:  <CAJ-Vmo=jCo-H8BwybFS3uaS3xQ4pxSz-hpxyEg0z2g3KSoErwQ@mail.gmail.com>
In-Reply-To: <20131219151606.GB71033@FreeBSD.org>
References:  <CAJ-VmomyPq_2K-MFhb7vt6MM7RBbmn7yaTzUXb7%2BN7TbW1RmHQ@mail.gmail.com> <20131219151606.GB71033@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 19 December 2013 07:16, Gleb Smirnoff <glebius@freebsd.org> wrote:
> On Wed, Dec 18, 2013 at 01:04:43PM -0800, Adrian Chadd wrote:
> A> How about we can this check in ip_output():
> A>
> A>         /*
> A>          * Verify that we have any chance at all of being able to queue the
> A>          * packet or packet fragments, unless ALTQ is enabled on the given
> A>          * interface in which case packetdrop should be done by queueing.
> A>          */
> A>         n = ip_len / mtu + 1; /* how many fragments ? */
> A>         if (
> A> #ifdef ALTQ
> A>             (!ALTQ_IS_ENABLED(&ifp->if_snd)) &&
> A> #endif /* ALTQ */
> A>             (ifp->if_snd.ifq_len + n) >= ifp->if_snd.ifq_maxlen ) {
> A>                 error = ENOBUFS;
> A>                 IPSTAT_INC(ips_odropped);
> A>                 ifp->if_snd.ifq_drops += n;
> A>                 goto bad;
> A>         }
> A>
> A> .. it's totally bogus in an if_transmit / SMP world. There's no
> A> locking and there's no guarantee that there will be headroom in the
> A> queue between this point and the later call to the if_output() method.
>
> My vote is to remove this. But better leave a comment that we need
> an API to send a bunch of packets (or fail them all) via an interface.

Yes. I think we need some path to evolve if_transmit to a) transmit
multiple frames as a transaction (eg a set of IP or 802.11 fragments)
at once, and b) be able to transmit multiple transactions at once.

Right now chaining packets together via m_nextpkt can only be used for
one or the other. We'd have to set flags in the mbufs to delineate the
transaction boundaries and .. ew.



-a



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=jCo-H8BwybFS3uaS3xQ4pxSz-hpxyEg0z2g3KSoErwQ>