Date: Tue, 4 Mar 2014 13:11:32 -0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: Eugene Grosbein <egrosbein@rdtc.ru> Cc: FreeBSD Net <freebsd-net@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: UDP transmit and no flowid Message-ID: <CAJ-VmonyxMuxh6oP-p3ztqk7uBfKS5FjjK-j-5mELQQw578Kag@mail.gmail.com> In-Reply-To: <5315C38A.1010508@rdtc.ru> References: <CAJ-VmomNsR5n8K7k%2BqcTAaAn0HiUcxmFVDxJUw8AD5ZyKHTn5w@mail.gmail.com> <5315C38A.1010508@rdtc.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 4 March 2014 04:14, Eugene Grosbein <egrosbein@rdtc.ru> wrote: > On 04.03.2014 08:17, Adrian Chadd wrote: > >> 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. > > There is a patch written by melifaro@freebsd.org to introduce > IP flow id generation and modified by me to add sysctl > net.inet.ip.skip_flowid_gen to disable id generation in run time > and return pre-patched behavior: > > http://www.grosbein.net/freebsd/patches/netisr_ip_flowid.diff > > I've tested it in production for mpd5-based high loaded BRAS, it works just fine. > It uses IP src/dst addresses and TCP/UDP/SCTP ports to feed jenkins_hashword() > and to fill m->m_pkthdr.flowid. Hm, is this actually going to work for all paths through ip_output? Only a couple of paths go via netisr_queue(); the rest go via ifp->if_output. Is that going to loop back through the netisr outbound path? For some workloads we'll want to fill this in with the topelitz hash that matches the RX flow from the NIC, just to keep locking/processing of that flow on the same core. And to answer Slawa's email - yes, mainly because it's a subset of what's needed for doing this for TCP. In the TCP case, the hashing is already done for us on inbound connections; but there's still the whole missing bits from Robert's work to tie in the pcbgroup handling and the whole multi-queue / multi-listener thing that Linux and now DragonflyBSD does. But there's a handful of silly things that need to be first investigated and checked - like, ensuring that it works fine with fragmented IP frames and re-encapsulated things - just to ensure that they don't break the RSS model. Why'd you have to do an m_pullup() here in this path, which ideally should just be a lookup only path? Are you actually seeing the IP/TCP headers spread across multiple mbufs? They're not being snuck into mbuf headroom at all? Thanks, -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonyxMuxh6oP-p3ztqk7uBfKS5FjjK-j-5mELQQw578Kag>