Date: Wed, 05 Mar 2014 11:14:58 +0700 From: Eugene Grosbein <egrosbein@rdtc.ru> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, "Alexander V. Chernikov" <melifaro@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: UDP transmit and no flowid Message-ID: <5316A4C2.6040100@rdtc.ru> In-Reply-To: <CAJ-VmonyxMuxh6oP-p3ztqk7uBfKS5FjjK-j-5mELQQw578Kag@mail.gmail.com> References: <CAJ-VmomNsR5n8K7k%2BqcTAaAn0HiUcxmFVDxJUw8AD5ZyKHTn5w@mail.gmail.com> <5315C38A.1010508@rdtc.ru> <CAJ-VmonyxMuxh6oP-p3ztqk7uBfKS5FjjK-j-5mELQQw578Kag@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05.03.2014 04:11, Adrian Chadd wrote: > 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? I cannot answer these questions, CC'ing author of the patch, Alexander Chernikov. Eugene Grosbein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5316A4C2.6040100>