[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1272378659.2295.193.camel@edumazet-laptop>
Date: Tue, 27 Apr 2010 16:30:59 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Brian Bloniarz <bmb@...enacr.com>
Cc: David Miller <davem@...emloft.net>, therbert@...gle.com,
netdev@...r.kernel.org, rick.jones2@...com
Subject: Re: [PATCH] bnx2x: add support for receive hashing
Le mardi 27 avril 2010 à 09:37 -0400, Brian Bloniarz a écrit :
> David Miller wrote:
> > How damn hard is it to add two 16-bit ports to the hash regardless of
> > protocol?
> >
> Come to think of it, for UDP the hash must ignore
> the srcport and srcaddr, because a single bound
> socket is going to wildcard both those fields.
>
For your application maybe ;)
Here, I have thousand of RTP flows to big mediagateways, so the
(srcaddr, dstaddr) is shared by all these flows.
Tom Herbert also wants a threaded DNS server.
For UDP, we could have a bitmap (system level ?) to say if a particular
destination port wants multi-cpu (RPS) spreading or not, even if the NIC
decided to use a single queue to submit frames to the host (ie mask the
src_addr and src_port). In this case, RFS on non conected UDP sockets
could be activated as well.
Or just a global sysctl to be able to mask the src_addr and/or src_port
in our software rxhash.
> So the best we can hope for is for the hash to
> include destport and destaddr? From looking at
> my BCM5709's multiq behavior, I think broadcom's
> hash includes the destaddr but not the destport.
Toepliz hash for UDP is a hash(src_addr, dst_addr)
Both src port and dst port are ignored.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists