From owner-svn-src-all@freebsd.org Sat Jun 15 18:48:33 2019 Return-Path: Delivered-To: svn-src-all@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 2088815CD3B6; Sat, 15 Jun 2019 18:48:33 +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 AACA586E5F; Sat, 15 Jun 2019 18:48:32 +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 14A5627001FF; Sat, 15 Jun 2019 14:48:31 -0400 (EDT) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu 14A5627001FF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1560624511; bh=iFmvzU9PDa2Z9sIzoffU+qbsdYrSyPaOyOBigNENRN4=; h=Subject:To:From:Date:From; b=sisc4FBGcTiPo3tzX1ZuRan223PAXl8g5ev8KoDF8Gw6N7WvY6/Bw1CIqHS/ztxI+ ouj5mHWWy0yx6cy3UcOzNS5e8nph75iz1WaX3XlsyHp49cbC0eNQbO0rxL+ZIi86Bv mXB/U03wuZFEt20yy9pYqs7HSc2oSwwPfUQOhEDmcKroXeRBvlmkjagNkDWWUrVa+i TUlQwizzNoLI/Pk3ObNcGxy+cqzAy+gdYlqxicPUvYd0PkM81WlYmpTwZMdVN9VfRm 5ptX665cwgNFIVe8hlVabGX/wrrPZ6OQVS1B4L4d4AtmikQGF2qHv4wGx2reFwyTZh liYOzAvgONY/w== Subject: Re: svn commit: r349055 - head/sys/net To: Marius Strobl Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201906151107.x5FB7f6N039968@repo.freebsd.org> <154077cb-14b1-1dbc-cb65-3233045963c0@cs.duke.edu> <20190615155940.GM6782@alchemy.franken.de> From: Andrew Gallatin Message-ID: <178554f8-27f4-d09c-0d6f-0f53febbf601@cs.duke.edu> Date: Sat, 15 Jun 2019 14:48:30 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190615155940.GM6782@alchemy.franken.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: AACA586E5F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.970,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2019 18:48:33 -0000 On 2019-06-15 11:59, Marius Strobl wrote: > On Sat, Jun 15, 2019 at 09:08:05AM -0400, Andrew Gallatin wrote: >> On 2019-06-15 07:07, Marius Strobl wrote: >>> Author: marius >>> Date: Sat Jun 15 11:07:41 2019 >>> New Revision: 349055 >> >>> Log: >>> - Replace unused and only ever written to members of public iflib(9) >>> structs with placeholders (in the latter case, IFLIB_MAX_TX_BYTES >>> etc. are also only ever used for these write-only members if at all, >>> so both these macros and members can just go). Using these spares >>> may render it possible to merge certain iflib(9) fixes to stable/12. >>> Otherwise, changes extending struct if_irq or struct if_shared_ctx >>> in any way would break KBI as instances of these are allocated by >>> the driver front-ends (by contrast, struct if_pkt_info as well as >>> struct if_softc_ctx instances are provided by iflib(9) and, thus, >>> may grow at least at the end without breaking KBI). >> >> Given the above, why replace ipi_tcp_sum in if_pkt_info with a spare? >> Given that if_pkt_info can grow, I would also expect it to be able to >> shrink. So I don't quite see why the spare is needed here. >> >> I also worry about carrying the other spares around forever. > > Yes, KBI-wise it should be also safe for instances of structures allocated > by iflib(9) to shrink at the end (though shrinking structures usually isn't > a concern when MFCing as such parts may just be omitted); changes altering > the offsets of members would be a problem regarding KBI. > Still, I don't like changing the size of publicly visible structures in > stable branches without a real good reason even if such a change doesn't > strictly break the KBI. So the plan is to MFC the spares but then to get > rid of the ones whose removal doesn't break KBI in head. > > Marius > Thanks, that makes sense Drew