From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A986FA00C4; Wed, 28 Sep 2022 21:48:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4FFBD4113C; Wed, 28 Sep 2022 21:48:31 +0200 (CEST) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by mails.dpdk.org (Postfix) with ESMTP id 1211B410FA for ; Wed, 28 Sep 2022 21:48:30 +0200 (CEST) Received: by mail-pl1-f169.google.com with SMTP id z20so5722308plb.10 for ; Wed, 28 Sep 2022 12:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date; bh=4CUa14Z9zpk3WsuJNjOW+e9R5N6gaAE20JUelqYoAok=; b=3uNvRYIZIG2Hg5WxfpEMpInfshScyo0+GfpDrac4Swh+0wOo3YRFOwMshZhfJQsvD3 5+kBXzqGJH5o82sRVO3bRIavmFKskYhhtApNKIV9P4OispgpgGN0MbBs00jkhq+pEHl6 ZHqvusW3zGxwU9hYpQ2OIwbjDhsGm+/rm6yFme1Lpqyw3lCHzASEvG+4sITfbiS9hkQz k2qMuElTNUC0JtruyucJ9u1MPNNiovsBIrGnw4Dif0iyn5ZH7oLJO7ObUAGc72b7e1FU wLIug6Kxyw11P5qoF2KelGPIMyW6cKC58Aj0k7pwMOAipIdI+OBSLFe6n9W6PDe+ooL3 mvGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=4CUa14Z9zpk3WsuJNjOW+e9R5N6gaAE20JUelqYoAok=; b=asWbtuAtyD4l4hnLAOfzdoqFNpJsRHbmy0O8Mmr/YSHZUBl3B9EuIsosUZA1ilwqOl pXUcB8mH38hYG5rp81y3LnbJHD4dtDVvCv5hYkNCsNID1BnCIxYuPTRnwcVFcC+AL8fk w8zjHSjTWnfOmbq+pDsB4giztNJc09Gcq4dkrX4nlKhaY7Mb/JY2GOfISB6ovERrxDnz eRqrEFrW+mUDi2RqiELSdEC6zLQCqzrp4htD12Cw4ozlkV/pHWinDLBG5YkRhak1Cvrt F6aBcXxhWa3XULWAo/ylty7V62piTlY6kCtITQ+lOzbxBx9+6YoXKXi4eAgwN+MnkL6/ tV7A== X-Gm-Message-State: ACrzQf3EYnxHzf2cCAOiednRoW7Eh4DKymtTYROMBRP6ZlO+LG6yIlGR O9r4odsnM0Zjnp3Sz77XRT9NVA== X-Google-Smtp-Source: AMsMyM4G596OVSFKDKkfcm6Lv2dTNQNqdlgIX8SxvF96d59emOgGuxH65uCpLaNynxo27tlHfmQ4Sg== X-Received: by 2002:a17:902:da82:b0:178:38ee:70b with SMTP id j2-20020a170902da8200b0017838ee070bmr1303880plx.85.1664394509202; Wed, 28 Sep 2022 12:48:29 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id c9-20020a170903234900b001780e4e6b65sm1998869plh.114.2022.09.28.12.48.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Sep 2022 12:48:29 -0700 (PDT) Date: Wed, 28 Sep 2022 12:48:27 -0700 From: Stephen Hemminger To: Olivier Matz Cc: Thomas Monjalon , Shijith Thotton , dev@dpdk.org, pbhagavatula@marvell.com, Honnappa.Nagarahalli@arm.com, bruce.richardson@intel.com, jerinj@marvell.com, mb@smartsharesystems.com, david.marchand@redhat.com Subject: Re: [PATCH v3 2/5] mbuf: add second dynamic field member for VA only build Message-ID: <20220928124827.790ba22f@hermes.local> In-Reply-To: References: <20220907134340.3629224-1-sthotton@marvell.com> <5861713.UjTJXf6HLC@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, 28 Sep 2022 14:52:47 +0200 Olivier Matz wrote: > On Wed, Sep 28, 2022 at 09:24:51AM +0200, Thomas Monjalon wrote: > > 21/09/2022 15:56, Shijith Thotton: > > > mbuf physical address field is not used in builds which only uses VA. It > > > is used to expand the dynamic field area. > > > > > > Signed-off-by: Shijith Thotton > > > > We cannot condition the use of the dynamic field. > > I think it is enough justification to reject this patch. > > I don't think it is an issue. > > > And about adding a compilation option for IOVA in the first patch of this series, > > I think it is not the direction the majority wants DPDK to go. > > We tend to avoid compilation options. > > In general, I agree that we don't want to have many custom compile-time options, > especially if they impact ABI. It has several issues that have already been > widely discussed. > > However, in this specific case, we can suppose that removing buf_iova is a > long-term goal (in years). Having this compile-time option is a way to test this > approach, and progressively prepare the drivers to support it. Then, in few > years (if we are still convinced), we may announce an abi breakage and switch to > this new mode by default. Since field is invalid if compile option is set, shouldn't the field be inside an #ifdef so that if a driver or application was to make the mistake of using that directly, it would fail at compile time instead of runtime. Leaving booby traps for applications and drivers is bad design.