fastforward/routing: a 3 million packet-per-second system?

[John Jasen]

in_input crept up into the top 5, versus fastforward.


Would PMC counters help?

 cat debug.lock.pref.stats.out-20140728-1 | sort -nk 4 | tail -5
       5         4         413         115         160      2      0  0
63 /usr/src/sys/kern/kern_condvar.c:145 (sleep mutex:Giant)
       1         1      148858        4095      650072      0      0  0
 11184 /usr/src/sys/kern/subr_turnstile.c:552 (spin mutex:turnstile chain)
       8        14    13747639      561636    72520256      0      0  0
689603 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry)
       3        20     3907071     2322975    72520256      0      0  0
2529589 /usr/src/sys/netinet/ip_input.c:1315 (sleep mutex:rtentry)
       3        17     3665247     3715117    72520256      0      0  0
8425384 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry)


On Sun, Jul 27, 2014 at 1:50 PM, Adrian Chadd <adrian at freebsd.org> wrote:

> Yeah, there's something odd going on. You shouldn't see any of that
> lock contention if flowtable is enabled. Thus I think there's
>
> Oh wait, the fastfwd code doesn't know about flowtables. I just looked
> at it (sys/netinet/ip_fastfwd.c.)
>
> Try disabling fastfwd for a test and see if the lock profile improves.
> (Set debug.lock.prof.reset=1 to clear the profiling data before you do it.)
>
>
> -a
>
>
> On 27 July 2014 05:58, John Jasen <jjasen at gmail.com> wrote:
> > I shouldn't even be coming close to maxflows in this test scenario.
> >
> > net.flowtable.enable: 1
> > net.flowtable.maxflows: 1042468
> >
> > On 07/26/2014 10:20 PM, Adrian Chadd wrote:
> >> Flowtable is enabled? That's odd, it shouldn't be showing up like that.
> >>
> >>
> >>
> >> -a
> >>
> >>
> >>
> >
>