Hi, On Tue, Nov 24, 2015, at 23:21, Alexei Starovoitov wrote: > On Tue, Nov 24, 2015 at 10:58:08PM +0100, Hannes Frederic Sowa wrote: > > > > > > > > > > interesting idea, but then remote host will be influencing local cpu > > > > > selection? > > > > > how remote can figure out the number of local cpus? > > > > > > > > Via rpc! :) > > > > > > > > The configuration shouldn't change all the time and some get_info rpc > > > > call could provide info for the topology of the machine, or... > > > > > > Configuration changes all the time. Machines crash, traffic redirected > > > because of load, etc, etc > > > > Yeah, same problem you have to handle with the kcm approach. > > not at all. No new remote configuration things are needed.
At some point you have to manage your ip address and if you move a host subnet or an ip address it should not matter a lot. > > Just use GRO engine and TCP PSH flag, maybe by making it more > > intentional via user space APIs on one connection. Wake up thread with > > one complete RPC message. If receiver eats more data it is no problem, > > if less, it will block as in your approach, too. Your worker threads > > must handle that anyway and can buffer and concatenate it to the next > > message to be processed. > > of course not. kcm reading threads don't have to deal with it. If there is no fallback for this you have to drop frames and kill the TCP connection for all your RPC endpoints. If you lost synchronization with the headers there is no way you will resync. > PS > just noticed that you've excluded all. By accident? > Feel free to reply to all. Oh, thanks, yes it was a fault on my side. For full transparency I reply. Bye, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
