From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id E1ADC594B for ; Mon, 11 May 2015 19:44:11 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YrrkL-0002Wl-8D; Mon, 11 May 2015 13:44:10 -0400 Date: Mon, 11 May 2015 13:43:59 -0400 From: Neil Horman To: Stephen Hemminger Message-ID: <20150511174359.GD8310@hmsreliant.think-freely.org> References: <1431364071-27298-1-git-send-email-stephen@networkplumber.org> <1431364071-27298-3-git-send-email-stephen@networkplumber.org> <8edea4c81f624728bb5f0476b680c410@BRMWP-EXMB11.corp.brocade.com> <20150511103259.3e602773@urahara> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150511103259.3e602773@urahara> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" , Stephen Hemminger Subject: Re: [dpdk-dev] [PATCH 2/6] rte_sched: expand scheduler hierarchy for more VLAN's X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 17:44:12 -0000 On Mon, May 11, 2015 at 10:32:59AM -0700, Stephen Hemminger wrote: > On Mon, 11 May 2015 17:20:07 +0000 > Neil Horman wrote: > > > Have you run this through the ABI checker? Seems like this would alter lots of > > pointer offsets. > > Neil > > No, I have not run it through ABI checker. > It would change the ABI for applications using qos_sched but will not > change layout of mbuf. > > But my assumption was that as part of release process the ABI version > would change rather than doing for each patch that gets merged. > You're correct that the ABI version can change, but the process is to make an update to doc/guides/rel_notes/abi.rst documenting the proposed changed, wait for that to be published in an official release, then make the change for the following release. That way downstream adopters have some lead time to prep for upstream changes. Neil