From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by dpdk.org (Postfix) with ESMTP id A83B41B884 for ; Wed, 17 Apr 2019 20:51:18 +0200 (CEST) Received: by mail-pl1-f173.google.com with SMTP id w24so12452174plp.2 for ; Wed, 17 Apr 2019 11:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Dl/2IWRWC+t4vjHCipUvVEtrAzt2NPos9/UMO/GGEHU=; b=TRpDUfsMqzGlck2x4d7GXvxLAc6sOMBaqH0LJmov0mQgYEIR7+yDOKyeWVvB44uDgw yd2TQqHiH3aCsA5iy4c1eq8sLdB0DnDA2/YKnYhpn0o3vruIbwi6Yys8Ti8SJekioPv1 HWaKghzb6zqRLEQUit9hdMwgJV8P1CKnQfmPp46m11mQUhloCLsodFIz7BqkaLR/uijK ZjEmySesdsTRTXJh1iAZkyPbAB0oDup1ov4NjnjYOfdXUR4EOuFU43Hq0XT7Fjg9d/Am ONt3J2AoWU/RSn/nuQGC9PY03YjSv1HInlM+bLOkZJ4OHhzR8g6HrhVcVDk6R4FUS+hh 8GhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Dl/2IWRWC+t4vjHCipUvVEtrAzt2NPos9/UMO/GGEHU=; b=Je2uQwlt+hGWFPglAMhX5MXabfOP0dnAQXLj2juKk09cbqQ9NV995/JeV67l2Cwdnb L7RzMP/nxqu13K6wn6eVnqnad5xmWg60yPxCvDz8qli2/9ZhVBeqN53qPu5x5ovhwfOw 3imjJUjmrxViuhiR9vMJXsqkU2OivyAXeSCIMllPX8v25WSTEvlOlBnFW3E+xpR6DY0b r1dv1VyDgVlFMPE8A0xqxEqlqqTgtbVcrQkdKbgLhyPGfGj6l2Y8AB2J19EvF2Tzbuts EbI3wuHj6J2LXZ2NlVHXj5K/FGVfqo9DOaOY9n0wKXpNWiMt+7eqQZs+Z4U6cgSq5Yjc RPIw== X-Gm-Message-State: APjAAAV0UWINUmrTj+cLfRfiYLhFgDuPVfI6+6OPkvimfFrQv+6LIYiR VEjbrsoS4dChVlkhul4ZS5RxSA== X-Google-Smtp-Source: APXvYqxgPJ8DW42ZBfqZmzDUZ3NK3MN4K7meE5qOhMz1aiUTpw7fq7KZ17gFtDxdZkFPqOBKkMyUmw== X-Received: by 2002:a17:902:28e9:: with SMTP id f96mr68445045plb.190.1555527077830; Wed, 17 Apr 2019 11:51:17 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 17sm74219229pgz.52.2019.04.17.11.51.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 11:51:17 -0700 (PDT) Date: Wed, 17 Apr 2019 11:51:10 -0700 From: Stephen Hemminger To: Jerin Jacob Kollanukkaran Cc: Bruce Richardson , Honnappa Nagarahalli , "dev@dpdk.org" , "Ananyev, Konstantin" , "thomas@monjalon.net" , Ray Kinsella , nd Message-ID: <20190417115110.5cb70832@hermes.lan> In-Reply-To: References: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] ABI and inline functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 18:51:19 -0000 On Wed, 17 Apr 2019 17:46:34 +0000 Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- > > From: dev On Behalf Of Bruce Richardson > > Sent: Wednesday, April 17, 2019 2:07 PM > > To: Honnappa Nagarahalli > > Cc: dev@dpdk.org; Stephen Hemminger ; > > Ananyev, Konstantin ; thomas@monjalon.net; > > Ray Kinsella ; nd > > Subject: Re: [dpdk-dev] ABI and inline functions > > > > > 2) Every function that is not in the direct datapath (fastpath?) > > > should not be inline. Exceptions or things like rx/tx burst, ring > > > enqueue/dequeue, and packet alloc/free - Stephen > > > > Agree with this. Anything not data path should not be inline. The next question > > then is for data path items how to determine whether they need to be inline or > > not. In general my rule-of-thumb: > > * anything dealing with bursts of packets should not be inline > > # I think, we need consider the how fat is the function too, > If it is light weight, probably we need to make it inline > # Except the forward case, In real world use case, it is not trivial make large > burst of packet to process it even though function prototype burst. > We may need to consider that > # For the given function if some argument is used with inline other function, > probably no point in making that function alone inline as the structure > is exposed in some other function. > > > * anything what works with single packet at a time should be inline > > > > > In this context, does it make sense to say that we will maintain API > > > compatibility rather than saying ABI compatibility? This will also > > > send the right message to the end users. > > > > > I would value ABI compatibility much higher than API compatibility. If someone > > is recompiling the application anyway, making a couple of small changes (large > > rework is obviously a different issue) to the code should not be a massive issue, I > > hope. On the other hand, ABI compatibility is needed to allow seamless update > > from one version to another, and it's that ABI compatiblity that allows distro's to > > pick up our latest and greatest versions. > > IMO, We have two primary use case for DPDK > > 1) NFV kind of use case where the application needs to run on multiple platform > without recompiling it. > 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated > Controller used. For fixed appliance use case, end user care more of performance > than ABI compatibility as it easy to recompile the end user application vs the cost of > hitting performance impact. Nobody cares about compatiablity until they have to the first security update. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id EF43CA00E6 for ; Wed, 17 Apr 2019 20:51:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4D9B91B890; Wed, 17 Apr 2019 20:51:20 +0200 (CEST) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by dpdk.org (Postfix) with ESMTP id A83B41B884 for ; Wed, 17 Apr 2019 20:51:18 +0200 (CEST) Received: by mail-pl1-f173.google.com with SMTP id w24so12452174plp.2 for ; Wed, 17 Apr 2019 11:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Dl/2IWRWC+t4vjHCipUvVEtrAzt2NPos9/UMO/GGEHU=; b=TRpDUfsMqzGlck2x4d7GXvxLAc6sOMBaqH0LJmov0mQgYEIR7+yDOKyeWVvB44uDgw yd2TQqHiH3aCsA5iy4c1eq8sLdB0DnDA2/YKnYhpn0o3vruIbwi6Yys8Ti8SJekioPv1 HWaKghzb6zqRLEQUit9hdMwgJV8P1CKnQfmPp46m11mQUhloCLsodFIz7BqkaLR/uijK ZjEmySesdsTRTXJh1iAZkyPbAB0oDup1ov4NjnjYOfdXUR4EOuFU43Hq0XT7Fjg9d/Am ONt3J2AoWU/RSn/nuQGC9PY03YjSv1HInlM+bLOkZJ4OHhzR8g6HrhVcVDk6R4FUS+hh 8GhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Dl/2IWRWC+t4vjHCipUvVEtrAzt2NPos9/UMO/GGEHU=; b=Je2uQwlt+hGWFPglAMhX5MXabfOP0dnAQXLj2juKk09cbqQ9NV995/JeV67l2Cwdnb L7RzMP/nxqu13K6wn6eVnqnad5xmWg60yPxCvDz8qli2/9ZhVBeqN53qPu5x5ovhwfOw 3imjJUjmrxViuhiR9vMJXsqkU2OivyAXeSCIMllPX8v25WSTEvlOlBnFW3E+xpR6DY0b r1dv1VyDgVlFMPE8A0xqxEqlqqTgtbVcrQkdKbgLhyPGfGj6l2Y8AB2J19EvF2Tzbuts EbI3wuHj6J2LXZ2NlVHXj5K/FGVfqo9DOaOY9n0wKXpNWiMt+7eqQZs+Z4U6cgSq5Yjc RPIw== X-Gm-Message-State: APjAAAV0UWINUmrTj+cLfRfiYLhFgDuPVfI6+6OPkvimfFrQv+6LIYiR VEjbrsoS4dChVlkhul4ZS5RxSA== X-Google-Smtp-Source: APXvYqxgPJ8DW42ZBfqZmzDUZ3NK3MN4K7meE5qOhMz1aiUTpw7fq7KZ17gFtDxdZkFPqOBKkMyUmw== X-Received: by 2002:a17:902:28e9:: with SMTP id f96mr68445045plb.190.1555527077830; Wed, 17 Apr 2019 11:51:17 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 17sm74219229pgz.52.2019.04.17.11.51.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 11:51:17 -0700 (PDT) Date: Wed, 17 Apr 2019 11:51:10 -0700 From: Stephen Hemminger To: Jerin Jacob Kollanukkaran Cc: Bruce Richardson , Honnappa Nagarahalli , "dev@dpdk.org" , "Ananyev, Konstantin" , "thomas@monjalon.net" , Ray Kinsella , nd Message-ID: <20190417115110.5cb70832@hermes.lan> In-Reply-To: References: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] ABI and inline functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190417185110.dqkj_kBKr1fHV9i59qBrl7JaMor38t-nT33VE6B6hCw@z> On Wed, 17 Apr 2019 17:46:34 +0000 Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- > > From: dev On Behalf Of Bruce Richardson > > Sent: Wednesday, April 17, 2019 2:07 PM > > To: Honnappa Nagarahalli > > Cc: dev@dpdk.org; Stephen Hemminger ; > > Ananyev, Konstantin ; thomas@monjalon.net; > > Ray Kinsella ; nd > > Subject: Re: [dpdk-dev] ABI and inline functions > > > > > 2) Every function that is not in the direct datapath (fastpath?) > > > should not be inline. Exceptions or things like rx/tx burst, ring > > > enqueue/dequeue, and packet alloc/free - Stephen > > > > Agree with this. Anything not data path should not be inline. The next question > > then is for data path items how to determine whether they need to be inline or > > not. In general my rule-of-thumb: > > * anything dealing with bursts of packets should not be inline > > # I think, we need consider the how fat is the function too, > If it is light weight, probably we need to make it inline > # Except the forward case, In real world use case, it is not trivial make large > burst of packet to process it even though function prototype burst. > We may need to consider that > # For the given function if some argument is used with inline other function, > probably no point in making that function alone inline as the structure > is exposed in some other function. > > > * anything what works with single packet at a time should be inline > > > > > In this context, does it make sense to say that we will maintain API > > > compatibility rather than saying ABI compatibility? This will also > > > send the right message to the end users. > > > > > I would value ABI compatibility much higher than API compatibility. If someone > > is recompiling the application anyway, making a couple of small changes (large > > rework is obviously a different issue) to the code should not be a massive issue, I > > hope. On the other hand, ABI compatibility is needed to allow seamless update > > from one version to another, and it's that ABI compatiblity that allows distro's to > > pick up our latest and greatest versions. > > IMO, We have two primary use case for DPDK > > 1) NFV kind of use case where the application needs to run on multiple platform > without recompiling it. > 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated > Controller used. For fixed appliance use case, end user care more of performance > than ABI compatibility as it easy to recompile the end user application vs the cost of > hitting performance impact. Nobody cares about compatiablity until they have to the first security update.