svn commit: r318166 - head/sys/netinet

[Gleb Smirnoff]

On Thu, May 11, 2017 at 12:55:14PM +0200, Fabian Keil wrote:
F> > Author: glebius
F> > Date: Wed May 10 23:32:31 2017
F> > New Revision: 318166
F> > URL: https://svnweb.freebsd.org/changeset/base/318166
F> > 
F> > Log:
F> >   There is no good reason for TCP reassembly zone to be UMA_ZONE_NOFREE.
F> >   
F> >   It has strong locking model, doesn't have any timers associated with
F> >   entries.  The entries theirselves are referenced only from the tcpcb
F> > zone, which itself is a normal zone, without the UMA_ZONE_NOFREE flag.
F> 
F> A side effect of the UMA_ZONE_NOFREE flag is that allocations
F> with M_NOWAIT (currently used tcp_reass()) are less likely to
F> fail.
F> 
F> Removing the UMA_ZONE_NOFREE in other TCP-related parts
F> "recently" caused (still unfixed) regressions like:
F> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209680
F> 
F> It would be great if there was a method to reserve a certain
F> number of items for the zone without having to rely on
F> UMA_ZONE_NOFREE but last time I checked there wasn't one.

Using UMA_ZONE_NOFREE for that problems is definitely a workaround.

The problems should be separated, there definitely is an ipfw
problem and TCP stack one. It is very strange that for an
already established connection we require allocating more memory
from these zones.

-- 
Totus tuus, Glebius.