tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: refactoring ip_output() and the L2 _output()

On 10 Feb, 2013, at 17:43 , Thor Lancelot Simon <> wrote:
> On Sun, Feb 10, 2013 at 07:05:01PM -0600, David Young wrote:
>> Speaking of radix trees, it seems that in an SMP networking stack the PCB
>> tables could be replaced by a couple of them.  The tree for unconnected
>> sockets would use keys
>>        [protocol (tcp|udp|...), local port (1..65535)]
>> for sockets binding the same port and INADDR_ANY, and use keys
>>        [protocol (tcp|udp|...), local port (1..65535)], local address]
>> for sockets bound to a particular local address.
> Wouldn't this have the unfortunate effect of squandering the ability
> of most modern network adapters to return the appropriate hash bucket
> for your (presumed, but reasonably, on the part of their designers)
> hashed connection datastructures on receive?

That's interesting.  Would it?  The stuff he's got listed there is all
unconnected socket state, not the full 5-tuple; it is what you would look
for if you couldn't find a full matching 5-tuple in your hash table.  Is
it possible to compute a hash only on the bits significant to those entries
without knowing the answer before you compute the hash?

Additionally, is there now a standard for computing a hash over a connection
identifier and, if so, where can I find it?  If not, how is this supposed
to work if you have two network adapters from different vendors, or if some
packet has come out of a tunnel and you need to compute the hash in software
to look up in the same connection table?  Or is it assuming that each interface
has a separate hashed connection data structure particular to that interface
and that all packets for a particular connection will come in the same

This sounds neat in theory, but I'm always suspicious since I've noticed it
isn't unusual for assists that network adapter designers include in their 
to be already squandered by making no sense if your operating system may do 
that windows doesn't.

Dennis Ferguson

Home | Main Index | Thread Index | Old Index