On Fri, Nov 14, 2014 at 2:58 PM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > On Fri, 2014-11-14 at 14:27 -0800, Andy Lutomirski wrote: > >> The people at the other end will be really pissed if that results in >> lots of reconnections. > > No reconnections necessary. > > I believe you misunderstood : On the 4-tuple (SADDR,SPORT,DADDR,DPORT), > you can pick for example SPORT so that hash(SADDR,SPORT,DADDR,DPORT) > maps to a known and wanted RX queue number. > > Once you know that, you use bind(SADDR, SPORT), then > connect(DADDR,DPORT). If the kernel had an API for this, I'd be all for using it. > > Anyway, if your hardware is able to cope with the few number of flows, > just use the hardware and be happy. > > Here we want about 10 millions sockets, there is little hope for > hardware being helpful. > It's the intermediate numbers that are bad. With ten flows, the current accelerated RFS works fine. With 10M flows, RFS is a lost cause and this solution is much nicer. With, say, 1k flows, accelerated RFS *deserves* to work perfectly, because the hardware has enough filter slots. But making it work reliably requires a ridiculously large hash table, and collisions cause silent bad behavior. --Andy > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
