Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Oct 2010 13:46:56 -0400
From:      Ryan Stone <rysto32@gmail.com>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        FreeBSD Current <current@freebsd.org>, freebsd-net@freebsd.org, Attilio Rao <attilio@freebsd.org>, Sergey Kandaurov <pluknet@freebsd.org>, Jack F Vogel <jfv@freebsd.org>, Ryan Stone <rstone@sandvine.com>, Ed Maste <emaste@sandvine.com>
Subject:   Re: [PATCH] Netdump for review and testing -- preliminary version
Message-ID:  <AANLkTimisSojDg2z_f1_v71evfooVdPQ44eu2Thhrf3O@mail.gmail.com>
In-Reply-To: <alpine.BSF.2.00.1010090121310.1232@fledge.watson.org>
References:  <AANLkTikA5OUYD1A9pqCqVEZ5qk%2BVECq8x-fnRXnpp0KE@mail.gmail.com> <AANLkTikau6omhWrXVM13zonFEPCxXM%2B8EqJauovDu0OU@mail.gmail.com> <alpine.BSF.2.00.1010090121310.1232@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson <rwatson@freebsd.org> wrote:
> +               /*
> +                * get and fill a header mbuf, then chain data as an
> extended
> +                * mbuf.
> +                */
> +               MGETHDR(m, M_DONTWAIT, MT_DATA);
>
> The idea of calling into the mbuf allocator in this context is just freaky,
> and may have some truly awful side effects.  I suppose this is the cost of
> trying to combine code paths in the network device driver rather than have
> an independent path in the netdump case, but it's quite unfortunate and will
> significantly reduce the robustness of netdumps in the face of, for example,
> mbuf starvation.

Changing this will require very invasive changes to the network
drivers.  I know that the Intel drivers allocate their own mbufs for
their receive rings and I imagine that all other drivers have to do
something similar.  Plus the drivers are responsible for freeing mbufs
after they have been transmitted.  It seems to me that the cost of
making significant changes to the network drivers to support an
alternate lifecycle for netdump mbufs far outweighs the cost of losing
a couple of kernel dumps in extreme circumstances.



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