Re: multiple rx/tx rings and interrupt delivery on newer nics

[Sepherosa Ziehau <sepherosa%gmail.com@localhost>]

On Tue, Mar 24, 2009 at 8:03 PM, Thor Lancelot Simon 
<tls%rek.tjls.com@localhost> wrote:
> On Tue, Mar 24, 2009 at 05:46:38PM +0800, Sepherosa Ziehau wrote:
>> On Thu, Jun 14, 2007 at 3:03 PM, Darren Reed 
>> <darrenr%fastmail.net@localhost> wrote:
>> >
>> > I believe the standard matching for packets is a 5-tuple:
>> > source address, destination address, protocol, source port, destination 
>> > port
>>
>> Nah, not 5 tuple.  And you will have a trouble time to figure out
>> protocol of the packet, if the NIC does not provide it in the RX desc.
>
> For many applications, just {saddr, daddr} is good enough to give you
> reasonable distribution of input packets over CPUs, which is good enough
> to let you get a lot of concurrency in the network stack with only a
> single network interface.
>
> The newer 8257x can actually go so far as to compute the TCP PCB hash

_All_ devices supporting RSS standard hash function could do the
{faddr,laddr,fport,lport} hash; this includes jme(4).  Intel's
extention on their PCIe devices is hashing non-frag UDP packet using
{faddr,laddr,fport,lport}.  BTW, _all_ 8257x support RSS, including
the relative weak 82573 in this product line.

> for us (well, this would require changing our PCB hash function, but
> that's no big deal) allowing a ton of the logic in ip_input and tcp_input

Yep, the Toeplitz hash function implemented in host does not have
noticeable performace hit (at least it is so on dragonfly)

> to be skipped, as well as memory access even to the packet _headers_ until
> quite late in the receive path, which is a neat trick indeed.

I don't know, but I think you still will have to check length fields
in ip header during ip_input(), which means you will have to touch ip
header earlier.

Best Regards,
sephe

-- 
Live Free or Die