[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1272549408.4258.189.camel@bigi>
Date: Thu, 29 Apr 2010 09:56:48 -0400
From: jamal <hadi@...erus.ca>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Changli Gao <xiaosuo@...il.com>,
David Miller <davem@...emloft.net>, therbert@...gle.com,
shemminger@...tta.com, netdev@...r.kernel.org,
Eilon Greenstein <eilong@...adcom.com>,
Brian Bloniarz <bmb@...enacr.com>
Subject: Re: [PATCH net-next-2.6] net: speedup udp receive path
On Thu, 2010-04-29 at 15:49 +0200, Eric Dumazet wrote:
> > I fork one instance per detected cpu and bind to different ports each
> > time. Example bind to port 8200 on cpu0, 8201 on cpu1, etc.
> >
>
> I guess this is the problem ;)
>
> With RPS, you should not bind your threads to cpu.
> This is the rps hash who will decide for you.
>
Sorry - I was not clear; i have the option of binding to cpu
vs the setsched api; but what i meant in this case is:
- for each cpu detected, fork
-- open socket
---bind to udp port cpu# + 8200
I could also bind to a cpu in the last step and i did notice it
improved distribution - but all my tests since apr23 dont do that ;->
>
> I am using following program :
>
I will try your program instead so we can reduce the variables
cheers,
jamal
--
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