From owner-svn-src-head@freebsd.org Mon Sep 25 20:23:52 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05667E234E3; Mon, 25 Sep 2017 20:23:52 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 85D2D6760A; Mon, 25 Sep 2017 20:23:51 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 0888D25D3857; Mon, 25 Sep 2017 20:23:47 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2EC97D1F950; Mon, 25 Sep 2017 20:23:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id Rlvo_8s0HqpP; Mon, 25 Sep 2017 20:23:45 +0000 (UTC) Received: from [192.168.124.1] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 174E8D1F7FD; Mon, 25 Sep 2017 20:23:44 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Stephen Hurd" Cc: "Stephen Hurd" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r323942 - head/sys/net Date: Mon, 25 Sep 2017 20:23:43 +0000 Message-ID: <681F1B2B-1CF6-41AC-9EED-B4790AB7CE95@lists.zabbadoz.net> In-Reply-To: <61486844-e6f1-2607-2113-599ebcb02c58@sasktel.net> References: <201709230135.v8N1ZE6S063264@repo.freebsd.org> <283397c7-a01e-3776-7ed3-b64d68003d0b@sasktel.net> <6F5DC92C-2CF6-4A33-9663-BFECB7DB65F2@lists.zabbadoz.net> <89d68ff8-84ed-83a6-4e77-9a321babe2fe@sasktel.net> <4523452E-79B0-494A-B44F-44DE4B747D69@lists.zabbadoz.net> <61486844-e6f1-2607-2113-599ebcb02c58@sasktel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6091) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 20:23:52 -0000 On 25 Sep 2017, at 17:04, Stephen Hurd wrote: > Bjoern A. Zeeb wrote: >> On 23 Sep 2017, at 23:46, Stephen Hurd wrote: >> >>> Bjoern A. Zeeb wrote: >>>> On 23 Sep 2017, at 6:32, Stephen Hurd wrote: >>>> >>>>> Bjoern A. Zeeb wrote: >>>>>> On 23 Sep 2017, at 1:35, Stephen Hurd wrote: >>>>>> >>>>>>> Author: shurd >>>>>>> Date: Sat Sep 23 01:35:14 2017 >>>>>>> New Revision: 323942 >>>>>>> URL: https://svnweb.freebsd.org/changeset/base/323942 >>>>>>> >>>>>>> Log: >>>>>>> Chain mbufs before passing to if_input() >>>>>>> >>>>>>> Build a list of mbufs to pass to if_input() after LRO. >>>>>>> Results in >>>>>>> 12% small packet forwarding rate improvement. >> I not saying anything against the change, I am just saying the commit >> message doesn’t describe what it does. > > Can you explain what was confusing about it or propose other wording? > I'm not sure what was confusing, and I'd like to avoid similarly > confusing messages in the future. I think it’s because I read “after LRO” as “after LRO processing happened” which is exactly not what is happening in that case; I know logically in the code order it’s “after LRO”. If I understand the change correctly (and I think jtl summarised it quite well already as well): “In cases when LRO is disabled or LRO is not consuming the packet, try to build an mbuf chain and pass the chain to if_input() thus lowering the per-packet overheads (*). For a packet forwarding case we have seen a 12% rate improvement for small packets.” (*) would be nice to describe them at this point so people understand where 12% come from (e.g., function call overhead, locking overhead, whatever ..) because that’s the reason you are doing the change. >> Also I am pretty sure this works with ether_input but not so much >> with fddi_input, iso88025_input, and ifdead_input is probably going >> to leak as well. > > Thanks for the heads up. They all seem to use m_freem(), so they > shouldn't leak. Right. My bad. > It doesn't look like they would actually work though (except > ifdead_input of course). Well, they’d work with a bit of packet loss I guess ;-) /bz