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 85334C6C0 for ; Tue, 23 Jun 2015 17:17:14 +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 1Z7PwZ-00024U-EW; Tue, 23 Jun 2015 11:17:09 -0400 Date: Tue, 23 Jun 2015 11:16:53 -0400 From: Neil Horman To: Thomas Monjalon Message-ID: <20150623151653.GA17251@hmsreliant.think-freely.org> References: <1434706885-4519-1-git-send-email-maciejx.t.gajdzica@intel.com> <1434706885-4519-2-git-send-email-maciejx.t.gajdzica@intel.com> <2173119.kJ61eenqfH@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2173119.kJ61eenqfH@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v5 01/13] port: added structures for port stats and config option 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: Tue, 23 Jun 2015 15:17:14 -0000 On Tue, Jun 23, 2015 at 03:55:25PM +0200, Thomas Monjalon wrote: > 2015-06-19 11:41, Maciej Gajdzica: > > /** Input port interface defining the input port operation */ > > struct rte_port_in_ops { > > rte_port_in_op_create f_create; /**< Create */ > > rte_port_in_op_free f_free; /**< Free */ > > rte_port_in_op_rx f_rx; /**< Packet RX (packet burst) */ > > + rte_port_in_op_stats_read f_stats; /**< Stats */ > > }; > > Isn't it breaking an ABI? > This is an interesting question. Strictly speaking, yes it breaks ABI because we're adding space, and if older applications statically allocate this structure, it will be smaller than the port library expects, potentially scribbling over someone elses memory. That said, I'm not sure this structure is meant to be accessed outside of the library. If it isn't, then we can feel comfortable that no one is going to access the data structure from code that was compiled out of sync with the defining library. The implication if thats true of course is that we should make this structure opaque outside of the library with a structure prototype and move its definition into the library private namespace, but I'm fine with doing that at a later date if the intention is not to have applications touch this structure. Regards Neil > > struct rte_port_out_ops { > > - rte_port_out_op_create f_create; /**< Create */ > > - rte_port_out_op_free f_free; /**< Free */ > > - rte_port_out_op_tx f_tx; /**< Packet TX (single packet) */ > > - rte_port_out_op_tx_bulk f_tx_bulk; /**< Packet TX (packet burst) */ > > - rte_port_out_op_flush f_flush; /**< Flush */ > > + rte_port_out_op_create f_create; /**< Create */ > > + rte_port_out_op_free f_free; /**< Free */ > > + rte_port_out_op_tx f_tx; /**< Packet TX (single packet) */ > > + rte_port_out_op_tx_bulk f_tx_bulk; /**< Packet TX (packet burst) */ > > + rte_port_out_op_flush f_flush; /**< Flush */ > > What is the goal of this change? Breaking the alignment? > > > + rte_port_out_op_stats_read f_stats; /**< Stats */ > >