On Fri, Nov 14, 2014 at 2:18 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Fri, Nov 14, 2014 at 2:16 PM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: >> On Fri, 2014-11-14 at 12:16 -0800, Andy Lutomirski wrote: >> >>> Sure, but how do I know that it'll be the same CPU next time? >> >> Because the NIC always use same RX queue for a given flow. >> >> So if you setup your IRQ affinities properly, the same CPU will drain >> packets from this RX queue. And since RFS is off, you have the guarantee >> the same CPU will be used to process packets in TCP stack. > > Right. My concern is that if RFS is off, everything works fine, but > if RFS is on (and the app has no good way to know), then silly results > will happen. I think I'd rather have the getsockopt fail if RFS is on > or at least give some indication so that the app can react > accordingly. > As I mentioned, there is no material functionality in this patch and it should be independent of RFS. It simply returns the CPU where the stack processed the packet. Whether or not this is meaningful information to the algorithm being implemented in userspace is completely up to the caller to decide. Tom > --Andy > >> >> This SO_INCOMING_CPU info is a hint, there is no guarantee eg if you use >> bonding and some load balancer or switch decides to send packets on >> different links. >> >> Most NIC use Toeplitz hash, so given the 4-tuple, and rss key (40 >> bytes), you can actually compute the hash in software and know on which >> RX queue traffic should land. >> >> > > > > -- > 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
