From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 04:15:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04F02CD4; Wed, 5 Mar 2014 04:15:15 +0000 (UTC) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 80403B67; Wed, 5 Mar 2014 04:15:13 +0000 (UTC) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.7/8.14.7) with ESMTP id s254F3ZZ008167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Mar 2014 05:15:03 +0100 (CET) (envelope-from egrosbein@rdtc.ru) X-Envelope-From: egrosbein@rdtc.ru X-Envelope-To: melifaro@freebsd.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id s254EwAj044959; Wed, 5 Mar 2014 11:14:58 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5316A4C2.6040100@rdtc.ru> Date: Wed, 05 Mar 2014 11:14:58 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: UDP transmit and no flowid References: <5315C38A.1010508@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-Report: * 3.0 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * 0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net Cc: FreeBSD Net , "Alexander V. Chernikov" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 04:15:15 -0000 On 05.03.2014 04:11, Adrian Chadd wrote: > Hi, > > On 4 March 2014 04:14, Eugene Grosbein 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