From owner-freebsd-arch@FreeBSD.ORG Tue Mar 4 21:11:34 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6987EBC2; Tue, 4 Mar 2014 21:11:34 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19C5AB77; Tue, 4 Mar 2014 21:11:34 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id i17so128566qcy.28 for ; Tue, 04 Mar 2014 13:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qKQ4j+oxLmZOqFB3ih1qQC9E/xuWFYtMliMjPcAe5Xk=; b=CL670+jLHEWklOlz1EtT/mzMgZRor9IdQjT+8P3GHza7TtFHzT5LMsCNnx87deofrd zzMP0kLo6QHVKd30KR1+mXtm6xN8DiMB8kBvLV5A1T8OVBq07cCcrbNjyEw8CC0fkCus z+IrGGQbPIQ9W2F/V+CzLFeWp6IVK6l/2NRW/Gj+HvoAcSrf0eJhEQ5QAUmjhyyCdz+4 WMQbKwrAbo0rKuOeSwKeC5yiuvYvCQ1ksaUKKK1xO7bNqVoZLIXZhAjVuSI5rU4ZiKN7 l4FgzLT1PBGefAF3Pr133dIqakjiTalAV9Oa3ZFfQAYkFUWhiLgJuJDib1i12zE6LNpy 19Kw== MIME-Version: 1.0 X-Received: by 10.229.171.8 with SMTP id f8mr2433919qcz.13.1393967492543; Tue, 04 Mar 2014 13:11:32 -0800 (PST) Received: by 10.224.16.10 with HTTP; Tue, 4 Mar 2014 13:11:32 -0800 (PST) In-Reply-To: <5315C38A.1010508@rdtc.ru> References: <5315C38A.1010508@rdtc.ru> Date: Tue, 4 Mar 2014 13:11:32 -0800 Message-ID: Subject: Re: UDP transmit and no flowid From: Adrian Chadd To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 21:11:34 -0000 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? Thanks, -a