From owner-svn-src-head@freebsd.org Fri Mar 8 19:24:06 2019 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52DA61526B7C; Fri, 8 Mar 2019 19:24:06 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12A00884E6; Fri, 8 Mar 2019 19:24:05 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [192.168.200.4] (c-71-56-186-158.hsd1.va.comcast.net [71.56.186.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gallatin) by duke.cs.duke.edu (Postfix) with ESMTPSA id 63E842700362; Fri, 8 Mar 2019 14:24:03 -0500 (EST) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu 63E842700362 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1552073043; bh=bhpt1V5aV/n09uRnzYTrG/EZQv64nyKST/OnBoAsU1k=; h=Subject:To:From:Date:From; b=ptUTOL1hxtOSKepnjJootEjUiqE76Za5zb/PZMbmokx+wrnDOwLMihCGotAS7zHIq TzMsBZiWu9eMrhbPZl9kmXJX0wSVKDj4CRhwCk76p2NvJ39RmFi7uXOlspaOFlJiLo 40iaqmu6y5eC48CeNc7EBYj3d/Si1iv3V7bQdt3L92qb+mQehRu3qmv6XJsqcep1bP IEwDioxLSpZJu5ji7O54KC4TjyLkDrFKpPNDzX2MXnB6OHMOmLEqPBxvb7xT6o4DoJ s7EomkL9RXXm7grKsfQyl5VkvKIpeH7zBxMNR6xASlo94EFNGANLXdft/453y4bAcD gRYhbugw/8EBg== Subject: Re: svn commit: r344817 - in head/sys: dev/e1000 net To: Matthew Macy , Eric Joyner Cc: src-committers , svn-src-all , svn-src-head References: <201903051912.x25JCqOj068140@repo.freebsd.org> From: Andrew Gallatin Message-ID: <3edbb822-54f1-eb64-537a-279c41a213ca@cs.duke.edu> Date: Fri, 8 Mar 2019 14:23:55 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 12A00884E6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.duke.edu header.s=mail0816 header.b=ptUTOL1h; dmarc=pass (policy=none) header.from=cs.duke.edu; spf=pass (mx1.freebsd.org: domain of gallatin@cs.duke.edu designates 152.3.140.1 as permitted sender) smtp.mailfrom=gallatin@cs.duke.edu X-Spamd-Result: default: False [-6.34 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:152.3.140.0/23]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.duke.edu:+]; RCVD_IN_DNSWL_MED(-0.20)[1.140.3.152.list.dnswl.org : 127.0.11.2]; DMARC_POLICY_ALLOW(-0.50)[cs.duke.edu,none]; MX_GOOD(-0.01)[cached: mx.oit.duke.edu]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.74)[ipnet: 152.3.128.0/17(-4.78), asn: 13371(-3.83), country: US(-0.07)]; ASN(0.00)[asn:13371, ipnet:152.3.128.0/17, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[cs.duke.edu:s=mail0816]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.89)[-0.891,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 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: Fri, 08 Mar 2019 19:24:06 -0000 On 3/5/19 4:06 PM, Matthew Macy wrote: > This represents a misunderstanding of how defines are used. This left > the option open to the user to enable the use of larger than page size > buffers as it does enable better performance. Over the course of a > long uptime memory can get too fragmented. However, this left it open > to the end consumer. > > I'd like to see this reverted with perhaps a better name for the > define and the addition of an explanatory comment. I'd strongly prefer that it stay removed. Since it is not hooked to an option, no user is ever going to find it. This really should have been a tuneable (since it is done at ring init time, rather than rx buffer alloc time), but nobody cared enough to make it actually usable. From brief memories of performance tuning 10G adapters 14 years ago, the differences between page-sized and 9k jumbos were minimal even back then (1/3 as many mbuf alloc/free, smaller chains). So I'm not convinced that it is worth bringing back in any form. My general feeling is that the more of this code that we can remove, the better. Iflib is tricky enough that it is already challenging to reason about and maintain. Removing code which is for all intents and purposes unreachable and never tested is Good Thing. Drew