Re: Some performance measurements on the FreeBSD network stack

> Because there were leaks, there were 100% panics for IPv6, ... at least on
> the version I had seen in autumn last year.
>
> There is certainly no one more interested then me on these in, esp. for v6
> where the removal of route caching a long time ago made nd6_nud_hint() a NOP
> with dst and rt being passed down as NULL only, and where we are doing up to
> three route lookups in the output path if no cached rt is passed down along
> from the ULP.
>
> If there is an updated patch, I'd love to see it.

Ok, I'm following up as this seems to be getting some interest. This
the relevant part of the last mail that I received from you. The final
part having been dedicated to the narrow potential ABI changes that
were to make it in to the release.

From: Bjoern A. Zeeb <bz_at_freebsd.org>
Date: Mon, Sep 19, 2011 at 3:19 PM
To: "K. Macy" <kmacy_at_freebsd.org>
Cc: Robert Watson <rwatson_at_freebsd.org>, rysto32 <rysto32_at_gmail.com>,
Qing Li <qingli_at_freebsd.org>

Sorry it's taking me so long while I was travelling but also now being
back home again.
I would yet have to find a code path through IPv6 that will a) not
panic on INVARIANTS
and b) actually update the inp_lle cache.

Once I stop finding the next hiccup going one step deeper into the
stack (and I made
it to if_ethersubr.c) I'll get to legacy IP and the beef and I'll hope
that all you
all will have reviewed and tested that thoroughly.

Checking whether a similar problem would exist in v4 I however found a possible
lle reference leak in the legacy IP path as well.

There's also a missed place where we do not update the generation counter (even
though kind of pointless place but still to do for completeness).

I am also pondering why we are not always invalidating the ro_lle cache (when we
update the ro_rt entry in the callgraph after tcp_output).  I wonder if we can
provoke strange results say changing the default route from something connected
on interface 1 to interface 2.

<...>

/bz

--
Bjoern A. Zeeb                                 You have to have visions!
        Stop bit received. Insert coin for new address family.

===================================================================

The only comment in here which was sufficiently specific to actually
take action on was: "pondering why we are not always invalidating the
ro_lle cache (when we update the ro_rt entry in the callgraph after
tcp_output)." Which was subsequently addressed by ensuring that the
LLE_VALID flag was actually meaningful by clearing it when the llentry
is removed from the interface's hash table in an unrelated commit
because of weird behaviour observed with the flow.

a) Where is the possible leak in the legacy path?

b) Where were the panics in v6?

In light of the fact that I don't or at least didn't have any means of
testing v6 (I can probably get a testbed set up at iX now) and the
netinet6 specific portions of the patch consist of 4 lines of code
which should really be entrusted to you given that your performance
parity work for v6 has actively being funded, it was clearly a mistake
to tie the fate of the patch as a whole to those narrow bits.

Once I get a response to a) and b) I'll follow up with a patch against
head. I'm sure whatever I had has bitrotted somewhat in the meantime.

Thanks for your help,
Kip