Date: Mon, 3 Mar 2014 17:17:08 -0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: FreeBSD Net <freebsd-net@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: UDP transmit and no flowid Message-ID: <CAJ-VmomNsR5n8K7k%2BqcTAaAn0HiUcxmFVDxJUw8AD5ZyKHTn5w@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi, So something I was told about whilst investigating RSS at Netflix was that the UDP path doesn't actually get set by anything unless you're using flowtable. So, if one doesn't define flowtable, the transmit path congests quite heavily through one TX queue. I was about to do up a simple hack to do a toeplitz hash in the UDP send path before it gets bumped up to ip_output() - that way it can set the flowid correctly. The other option is to do a topelitz hash in ip_output() if m_flowid isn't set. The downside there is that we'd have to check whether it's actually a TCP, UDP, or IP flow before we assign it a flowid. In any case, this would likely decongest the transmit path quite a bit for UDP send. It's still not completely RSS-y (we would still need to line up transmit and receive paths to minimise lock contention) but it seems like a necessary first step in that direction. What do people think? I'll try this out in the next week or two once I've sorted out my employment situation and I can reserve some time on the netperf cluster. (before people ask "why udp?" - I'm kinda fed up with memcached performing much worse on freebsd than linux. Since fixing the UDP side of things requires a subset of the same work needed for TCP, I figure we should tackle UDP first.) Thanks, -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomNsR5n8K7k%2BqcTAaAn0HiUcxmFVDxJUw8AD5ZyKHTn5w>