> Well, if you _really_ want the load spread, you may need to use a multiqueue
quoted text
> (at least inbound if not also later outbound) interface, "know" how the NIC
> will hash and then have N distinct port numbers each assigned to a LISTEN
> endpoint.  The old song and dance about making an N CPU system look as much
> like N single-CPU systems and all that...
>

Yep that's what I really want, except for the fact that I can only use
a single port for the server--  all flows could be nicely distributed
by the NIC multiqueue, but I still have the problem of how to ensure
that the accepting thread for a connection is run on the same CPU as
the interrupt and SYN processing were.

quoted text
> Unless there are NICs you can "tell" where to send the interrupts, which IMO
> is preferable - I have a preference for the application/scheduler telling
> "networking" where to work rather than networking (or the NIC) telling the
> scheduler where to run a thread - the archives of either here or netnews
> will probalby pull-up stuff were I've talked about Inbound Packet Scheduling
> (IPS) vs Thread Optimized Packet Scheduling (TOPS) and limitations of
> simplistic address hashing to pick a queue/processor/whatnot :)
>

NICs are already doing steering based on tuple hash (RSS), and I think
some will allow specifying the CPU for interrupt based on RX flow.
Maybe this would address the issues of Inbound Packet Scheduling?

Thanks for the pointers on IPS and TOPS.  Out of curiosity has there
been an effort to do TOPS on Linux?  We are doing something very
similar in software RSS with a fair amount of success (I posted
patches for this a while back).

Tom
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html