> -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall > Sent: Wednesday, June 17, 2015 5:37 AM > To: dev at dpdk.org > Subject: Re: [dpdk-dev] [dpdk-announce] important design choices - > statistics - ABI > > On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote: > > There were some debates about software statistics disabling. > > Should they be always on or possibly disabled when compiled? > > We need to take a decision shortly and discuss (or agree) this proposal: > > http://dpdk.org/ml/archives/dev/2015-June/019461.html > > This goes against the idea I have seen before that we should be moving > toward > a distro-friendly approach where one copy of DPDK can be used by multiple > apps > without having to rebuild it. It seems like it is also a bit ABI hostile > according to the below goals / discussions.
Matthew, thanks for your input. As Thomas also mentions, it would be good to first read the proposal on the guideline (http://dpdk.org/ml/archives/dev/2015-June/019461.html). In the guideline proposal, we are addressing the topic of preventing the ABI changes due to library statistics support, it would be good to get your opinion on that, I am not sure you saw it. Given DPDK paramount focus on performance, I think probably provides the best solution for ABI compatibility in this case. > > Jemalloc is also very high-performance code and still manages to allow > enabling and disabling statistics at runtime. Are we sure it's impossible for > DPDK or just theorizing? A performance improvement for one environment might still be an overkill for DPDK run-time environment. Stats cannot be enabled/disabled at run-time without performance impact, as it typically requires testing a persistent flag for incrementing the stats counters, which requires a conditional branch instruction. Sometimes the branches are predicted correctly, sometimes not, and in this case the CPU pipeline needs to be flushed; typical branch misprediction cost is ~14 cycles, which is important given a packet budget of ~200 cycles. When only a small number of branches are present in the (application + library) code, they are predicted correctly, so I am sure that for a simple test application like l3fw the cost of run-time enabled stats is not visible. The problem is that real applications are much more complex and they typically have a lot of conditional branches, out of which the library stats test is just one of them, so they cannot be all predicted correctly, hence the cost of stats run-time enablement becomes very much visible. > > > During the development of the release 2.0, there was an agreement to > keep > > ABI compatibility or to bring new ABI while keeping old one during one > release. > > In case it's not possible to have this transition, the (exceptional) break > > should be acknowledged by several developers. > > Personally to me it seems more important to preserve the ABI on patch > releases, like 2.X.Y going to 2.X.Z. But maybe I missed something? > > > During the current development cycle for the release 2.1, the ABI question > > arises many times in different threads. > > Most but not all of these examples point to a different issue which > sometimes > happens in libraries... often seen as "old-style" versus "new-style" C library > interface. For example, in old-style like libpcap there are a lot of structs, > both opaque and non-opaque, which the caller must allocate in order to run > libpcap. > > However new-style libraries such as libcurl usually just have init functions > which initialize all the secret structs based on some defaults and some user > parameters and hide the actual structs from the user. If you want to adjust > some you call an adjuster function that modifies the actual secret struct > contents, with some enum saying what field to adjust, and the new value > you > want it to have. > > If you want to keep a stable ABI for a non-stable library like DPDK, there's a > good chance you must begin hiding all these weird device specific structs all > over the DPDK from the user needing to directly allocate and modify them. > Otherwise the ABI breaks everytime you have to add adjustments, > extensions, > modifications to all these obscure special features. > > Matthew.
