Open brho opened 8 years ago
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.
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.