Fix our networking stack hash tables

[brho]

http://comments.gmane.org/gmane.os.plan9.general/76188

We have this problem too. The hash tables might need a little more work too. We have multiple NHASH defines which we might be able to consolidate.

[brho]

So gmane is dead. Whoops. Somehow, I found another link to the email describing the problem:

https://marc.info/?l=9fans&m=143380302809660&w=2

No amount of searching came up with that, but I did manage to do a search like this site:gmane.org os.plan9.general, and from the few results, interpolated the ID 76188 to around June/July 2015.

Having learned my lesson, here's the bug:

List: 9fans
Subject: [9fans] bug in network stack regarding Ipht
From: yoann padioleau <aryx.padator () gmail ! com>
Date: 2015-06-08 22:35:57
Message-ID: E20A10D8-82E6-4CF5-9CCD-FB140ABA4E44 () gmail ! com
[Download message RAW]

Hi,

I think I=E2=80=99ve found a bug in the network stack.
in 9/ip/ip.h there is
struct Ipht
{
Lock;
Iphash *tab[Nipht];
};

where Night is 521,

but then in 9/ip/ipaux.c there is

ulong
iphash(uchar *sa, ushort sp, uchar *da, ushort dp)
{
return ((sa[IPaddrlen-1]<<24) ^ (sp << 16) ^ =
(da[IPaddrlen-1]<<8) ^ dp ) % Nhash;
}

where Nhash is just 64,

so lots of entries in Ipht.tab will never be used. This slows down every =
ip+port lookups in the UDP and TCP code.

Digging this up was quite the pain in the ass.