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 450954368F; Wed, 6 Dec 2023 17:46:45 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 105DB4029C; Wed, 6 Dec 2023 17:46:45 +0100 (CET) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2043.outbound.protection.outlook.com [40.107.92.43]) by mails.dpdk.org (Postfix) with ESMTP id B2F254021E for ; Wed, 6 Dec 2023 17:46:42 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hf9rRNMDr1FWvn1zXovPDMVa7l//MhySo4N9ZUIA9Y3wOPEzQy1xPb77sfCe06vfeb5bwP/YUncloA4X65ECSoTrYO9HhEwfabqq7jKAh0qICpD4JV9SJ2YeIx+JzabFlx4ahuf9JalbIjgbI6LMNq1/2yWJD41Owdo6mUbZas659/5vH0cNXLyjR0ICvXWqtvUHH5rHOdBf0hoV0ASiYb8S4tPsXgB1qrTB65z1F8YEum0gs34pQvuvhfgD67AfqKZDkZ4RAxQGCOl18BwOJXphZfHl+18Xg8mUCvsqMxiVw6KrqjzXtSXgRINFyKJsdddhXEA3Hroo+pX7Yqn9Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZSR0OZxgIXan1ckNHBRHf1+dOuN1gy8bMJfk9iv8z/Y=; b=LCsFtq44q8m7rXOyNC7pELDNLjEGJwKwhbIpOV6swRYPVQAjUMWVjmE3L/hGTJFGVGdMnUFHOvhhrs9AAr+1+eesniRebgwubgJ9o47C9tt7csaMNBru7ELJWApLonndq6uzRJ2rliQle6nF5G3F9Qv9T0b1Ia7SB3VfTgDvJmbGNO53JZQmmyseDynK6kDWQBqV5ugx41vma7xJLG/BWFBX2Rql55Jz+DNDvTyg/2drQv4CM2ZELGd51HvOwMKGPOOCL8LAp3chkUaAD4lPFCRD7CBrNT2qlQiIVmeFPrZS/711JwYTVfpzjgY9cdwl6BXLk5yVmWq3q4BxVHlGUg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZSR0OZxgIXan1ckNHBRHf1+dOuN1gy8bMJfk9iv8z/Y=; b=4qf/ZvcOTV/hklzMib3wEpg75/t7wZX/OEvW2tD0SGs2vjZlPEC317BFbQt0awXigTroLrusqZSVPIonXcUkwnRFtJNua8QKSx/jbwE/7hkAn4rj/tVq4f4g4GZ5K41IarcEKIee5aD95bVyo01AYXdrcbdsTf6O9sWsJorOU6U= Received: from MN2PR12MB3085.namprd12.prod.outlook.com (2603:10b6:208:c5::29) by DM4PR12MB7719.namprd12.prod.outlook.com (2603:10b6:8:101::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7068.25; Wed, 6 Dec 2023 16:46:39 +0000 Received: from MN2PR12MB3085.namprd12.prod.outlook.com ([fe80::579d:6ed5:68a6:3cba]) by MN2PR12MB3085.namprd12.prod.outlook.com ([fe80::579d:6ed5:68a6:3cba%3]) with mapi id 15.20.7068.025; Wed, 6 Dec 2023 16:46:38 +0000 From: "Varghese, Vipin" To: Bruce Richardson CC: "Dumitrescu, Cristian" , "dev@dpdk.org" , "Yigit, Ferruh" , "Parikh, Neerav" Subject: Re: [PATCH] cfgfile: increase value length Thread-Topic: [PATCH] cfgfile: increase value length Thread-Index: AQHaKDe4yCtpk7vSyU+P/DqWnXg8prCcPeuAgAADiQCAABy+U4AACUCAgAAMNlE= Date: Wed, 6 Dec 2023 16:46:38 +0000 Message-ID: References: <20231206112952.1588-1-vipin.varghese@amd.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Enabled=True; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_SetDate=2023-12-06T16:46:37.505Z; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Name=General; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_ContentBits=0; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Method=Standard; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN2PR12MB3085:EE_|DM4PR12MB7719:EE_ x-ms-office365-filtering-correlation-id: e6b4ccfd-bcc4-48ca-3b09-08dbf67aead2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ADWFr5AsYSIYLMclpWpXyA55s2IT6hL2oxaaDTR9UGXA7NggqfDEgM6R09ZKM3slMHMihw+6BOxcEmWYf28X2AXZNk0uAClNUVhCBlWp9hnstfD3ogOuPo/e5kPYdPxUYWwAYnXZxvU7JPyV9Pb7A4XHtTOpLBigNYO5wq6/hG+6fb1MawJKC3AajE46ORHfg57j7X+vVHgLz5U1k8UAMnMCJe6vKrWS5tIi9AEO2n0FsxHHeCPM/wNQvYqsit27o0MT73+VBkEpEDq6QfYVVcTPfOcF7laIyqSJr9LW3aziZV5w3JqLrhMGgnZJNCm5juNRnJTcOr3tw5jBfgUrqHqZNqe3GjV0QMEfb61UN2sJrVOX6AzvGD89RyQ81abDdi8QizXnvUS0ToXN28kOXXnuUFg5WiG2JJY46Y6n2u++sVviXyiS3MB0JL9CPEUxWUruga3p456bqLowTQz+HaSFoDOozZwyRKdG+uNRhgXdelsEt3bvc+Vxk1/EZsrRT0KMloo6gc6Q/FyPJbWHr/iMfrz4VLuyBACvPeL28FT227yHnICreQCEe7uo/ePcPs0azggwO2LZ+GU69i54pJDwW6BF8Kesk+RLpu0M0hD5/BhizzgloDLaOZyRerMq5EEnoDT9xW81FWxzgatEqg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR12MB3085.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(366004)(346002)(376002)(396003)(136003)(230922051799003)(230173577357003)(230273577357003)(186009)(64100799003)(451199024)(1800799012)(38100700002)(91956017)(166002)(66946007)(76116006)(19627405001)(122000001)(83380400001)(26005)(53546011)(9686003)(7696005)(6506007)(71200400001)(21615005)(478600001)(1015004)(66476007)(66556008)(316002)(6916009)(66446008)(64756008)(55016003)(54906003)(86362001)(52536014)(8676002)(4326008)(8936002)(5660300002)(2906002)(33656002)(38070700009)(41300700001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?txwkrZpCJQLKOuEo33JcySXpabI8lNXob84UOWRp1HS2ieQCQyI//Ivw?= =?Windows-1252?Q?D76JVCuOgFXnkQwavdwmcMLnV/4HS8wjUxr8LuiKR8oAfQ1Vd7bQIOxk?= =?Windows-1252?Q?NrwuNNWgvHJAKx0CN5pySZIwRurd8zb//GtVy469tIs2O0NOsYp7Oa6X?= =?Windows-1252?Q?E6KF53sadF0Rs7wqYQvLu+Dgk5z7emnNhPz1slPMZd235CldTjqN8m8Q?= =?Windows-1252?Q?YoCTMWOdaOzhxSuONNXOjOkBMPdetB9OAof2cA2iuh0N4uqAuJSNFwps?= =?Windows-1252?Q?easfiN+X8NOVSIw7h6XZ8HaMHAwbqFyXd5tkMi8KcHzLUsS6jAcE+1eE?= =?Windows-1252?Q?ku091ftN7cDWTxUTQEbSk/doi+mKhO3NzX2JlMz9rBA3sS6s4LlKB32m?= =?Windows-1252?Q?y15QGqJRZdvqhW0bOH6+Q4/VEvpyDgsDyrhKXN7qguWKftm++w/+bJYQ?= =?Windows-1252?Q?MDYJY4mcoAH9WB2AtPh6V+iZLDSyQ/XaMb9Hrwru7op98PwgL0BAE8xQ?= =?Windows-1252?Q?JgDp5kpglHkcTMm+2duElKQ6rJRxn+74+frIpV9P5uQQIDGtneQPjUXC?= =?Windows-1252?Q?xF94ymsLmoF9mRrDVv8rnyARjvrFeYKQJN4MSoQo8tIJUNmbxYaasx+N?= =?Windows-1252?Q?OHVFYAoK/GXWOeWsioObipXv7PibiDELbmxp4A+Ggb4V5z4/wD3ZlcIt?= =?Windows-1252?Q?JQwJ3EcGu4Fj0/O8yO/EpV6TwejxM82AsP6+HH8ezoat9rgsmM+xansv?= =?Windows-1252?Q?Euu3kehNvTDmNLkRQKMumhUv2gOkQ3tizDF23r0Ozr/oOn98tzsUMjlQ?= =?Windows-1252?Q?q17cz+7ynaipP+JMHvPEnM79NENmryeD3sPVesVHqvUKDu5eb0Bt56lm?= =?Windows-1252?Q?I2lv5t6trdMpjQpN2n0TNKmIjUttVx7XvQij3xtWlqLYiYOQ5v2OhbNF?= =?Windows-1252?Q?s1mAunTrMht4PFQxMJJkN03XVYjCOSuNgVl+TCVZgVp93wyDgwUesBsS?= =?Windows-1252?Q?lpzJqXvL/aP72FUo/+thHbijTG9rU3f/k1zQcPwcYPCxxvvgMbmCChHH?= =?Windows-1252?Q?BumPnzEdOaGo2hac2Crc6h5rAtF5LqaUqUaqOy/CDH3nt5Zv12jkUM0m?= =?Windows-1252?Q?zdZU1wVnLbYYMVDI+KUiW1mcB0qdABMdYtv7K7HVo+JZ2ZhRCf8uT1wY?= =?Windows-1252?Q?CoutXUB1jENE5aKrgX6ARnHY+002hN4Nn9O7TNG2PU4O7vaHwqt3HgfP?= =?Windows-1252?Q?BK5iXdxG5VrOWxKAs53dgr3HbqSGmJFOaUnfW1ugmefK6dTGqFLo/3OP?= =?Windows-1252?Q?0aQgKaQRoKzyT8I4kydBbIWfgQPgGtUMtACNR3/mZhwqzB/coowXCyeJ?= =?Windows-1252?Q?vk6qRZ52jT/nSmHBCVxYyTrCNJZKsExmSDr4vUgqFeicPgr8+ZeIHaPT?= =?Windows-1252?Q?FSA5S4jKwpE/mMgQvSnmGH1L5O5hXN9q+7K0E+AckveMZg8x3ICOj2Q1?= =?Windows-1252?Q?PaHwQxS6R8q7gVtIp1mLa4VZi5cYOjENa+GB7TJlbG4af7fmmI09DTnU?= =?Windows-1252?Q?AYS3vqmT9vWezY9o1hbF7jfHCEp54cujuHK/0Nyrt1++KBE5uvCMnUVN?= =?Windows-1252?Q?NNtBkbuuK+/MMPw77Ltm/a88oSdDXc/1oKw3DyWadzzoRqI0P+Zoq7nd?= =?Windows-1252?Q?Y0z5jxWk36I=3D?= Content-Type: multipart/alternative; boundary="_000_MN2PR12MB3085F63F40533093FC9025868284AMN2PR12MB3085namp_" MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB3085.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e6b4ccfd-bcc4-48ca-3b09-08dbf67aead2 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2023 16:46:38.8561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gwI4n+6foZqsRNejoJMiW3L8n5PKikb/Dv3Auk/tOCYWBgaK0uAtJPlB1uMaYIgWIB5xPLHoaZa10KlQnVoXMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7719 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 --_000_MN2PR12MB3085F63F40533093FC9025868284AMN2PR12MB3085namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [AMD Official Use Only - General] From: Bruce Richardson Sent: 06 December 2023 21:20 To: Varghese, Vipin Cc: Dumitrescu, Cristian ; dev@dpdk.org ; Yigit, Ferruh ; Parikh, Neerav Subject: Re: [PATCH] cfgfile: increase value length Caution: This message originated from an External Source. Use proper cautio= n when opening attachments, clicking links, or responding. On Wed, Dec 06, 2023 at 03:22:41PM +0000, Varghese, Vipin wrote: > [AMD Official Use Only - General] > > Thanks Bruce & Cristian for the comments. > An increase seems ok to me, but is an 8x increase really necessary? If > lines in the config files are over 1k in size, then it implies that > some > other mechanism would surely be better for configuration. > Can we make do with an increase to 512 only? > VV> We encountered this issue > [1]https://bugs.dpdk.org/show_bug.cgi?id=3D1333 trying to use multiple > queue with DSA. But I hear you 256 to 2048 is big jump. > Happy to compromise with 1K. > VV> Sure let me update this is v2. > Since there is a ABI breakage, > [2]https://patchwork.dpdk.org/project/dpdk/patch/20231206112952.1588-1= - > vipin.varghese@amd.com/ I will re work and share v2. Looking at the bugzilla, I still think even an increase to 1k is too much, and that we should look to adjust the config file format in some way to accomodate these longer line settings. Based on my testing 32 devices with the current format 2048B are appropriat= e. That 4 DSA devices with 8 queues each. Taking the specific example in the bug: * each entry in the line is wasting 5 characters with the string "lcore" * each PCI ID is starting with 0000, so we can do like EAL does and assume PCI domain is "0000" if just the BDF is given. This may involve changes to the PCI driver in question, since i assume these queues are names rather than addresses, but it would make them easier to address. If we did these two items, then: lcore_dma=3Dlcore10@0000:00:04.2-q0,lcore12@0000:00:04.2-q1,lcore13@0000:00= :04.2-q2,lcore14@0000:00:04.2-q3,lcore15@0000:00:04.2-q4,lcore16@0000:00:04= .2-q5,lcore17@0000:00:04.2-q6,lcore18@0000:00:04.2-q7,lcore19@0000:00:04.4-= q0,lcore20@0000:00:04.4-q1,lcore21@0000:00:04.4-q2,lcore22@0000:00:04.4-q3,= lcore23@0000:00:04.4-q4,lcore24@0000:00:04.4-q5,lcore25@0000:00:04.4-q6,lco= re26@0000:00:04.4-q7 becomes: lcore_dma=3D10@00:04.2-q0,12@00:04.2-q1,13@00:04.2-q2,14@00:04.2-q3,15@00:0= 4.2-q4,16@00:04.2-q5,17@00:04.2-q6,18@00:04.2-q7,19@00:04.4-q0,20@00:04.4-q= 1,21@00:04.4-q2,22@00:04.4-q3,23@00:04.4-q4,24@00:04.4-q5,25@00:04.4-q6,26@= 00:04.4-q7 a reduction from 394 chars to 234 (10 chars per device). I see what you are suggesting, even though DPDK documentation states 9. EAL= parameters =97 Data Plane Development Kit 23.11.0 documentation (dpdk.org)= `<[domain= :]bus:devid.func>`, omit the domain to `bus:devid.func>`. That will reduce = the bytes I agree. However, a better alternative may be to split up the lcore_dma item entirely, so that we always have one element per line: lcore_dma0=3Dlcore10@0000:04.2-q0 lcore_dma1=3Dlcore12@0000:04.2-q1 .... lcore_dma15=3Dlcore26@0000:04.4-q7 What is especially good about using this is a solution is that it can be fu= lly backward compatible and has no ABI issues. If an "lcore_dma=3D" line exists= , we can split it, otherwise look for lcore_dma0, lcore_dma1 etc. Ok, but this means the test-dma-perf will need parsing changes and cfgfile = library. As I stated above, the need for really long lines in a config file is a symptom of a more serious config problem, rather than an issue with the cfgfile lib itself. I do not fully agree to this statement, here are my 2 points 1. current code is `#ifndef CFG_VALUE_LEN` which means, the user can change th= e value using compiler flag `-DCFG_VALUE_LEN=3D[user desired value]` as cfl= ags. 2. If not declared as CFLAGS configuration value is assumed to be hardened to = take only 256 Hence the reasoning would be `it was not assumed there would be change from= 256B was not expected or explored. If 256B is the hardlimit then we should= not have used #ifndef`. But +1 for changing the parsing logic. /Bruce --_000_MN2PR12MB3085F63F40533093FC9025868284AMN2PR12MB3085namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

[AMD Official Use Only - General]


From:=  Bruce Richardson <bruce.richardson@intel.com>
Sent: 06 December 2023 21:20
To: Varghese, Vipin <Vipin.Varghese@amd.com>
Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;= dev@dpdk.org <dev@dpdk.org>; Yigit, Ferruh <Ferruh.Yigit@amd.com&= gt;; Parikh, Neerav <Neerav.Parikh@amd.com>
Subject: Re: [PATCH] cfgfile: increase value length
 
Caution: This message originated from= an External Source. Use proper caution when opening attachments, clicking = links, or responding.


On Wed, Dec 06, 2023 at 03:22:41PM +0000, Varghese, Vipin wrote:
>    [AMD Official Use Only - General]
>
>    Thanks Bruce & Cristian for the comments.
>    An increase seems ok to me, but is an 8x increase re= ally necessary? If
>    lines in the config files are over 1k in size, then = it implies that
>    some
>    other mechanism would surely be better for configura= tion.
>    Can we make do with an increase to 512 only?
>    VV> We encountered this issue
>    [1]https://bugs.dpdk.org/show_bug.cgi?id=3D1333 tryi= ng to use multiple
>    queue with DSA. But I hear you 256 to 2048 is big ju= mp.
>    Happy to compromise with 1K.
>    VV> Sure let me update this is v2.
>    Since there is a ABI breakage,
>    [2]https://patchwork.dpdk.org/project/dpdk/patch/202= 31206112952.1588-1-
>    vipin.varghese@amd.com/ I will re work and share v2.=

Looking at the bugzilla, I still think even an increase to 1k is too much,<= br> and that we should look to adjust the config file format in some way to
accomodate these longer line settings.

Based on my = testing 32 devices with the current format 2048B are appropriate.
That 4 DSA devices with 8 queues each= .

Taking the specific example in the bug:
* each entry in the line is wasting 5 characters with the string "lcor= e"
* each PCI ID is starting with 0000, so we can do like EAL does and assume<= br>   PCI domain is "0000" if just the BDF is given. This may in= volve changes
  to the PCI driver in question, since i assume these queues are names=
  rather than addresses, but it would make them easier to address.

If we did these two items, then:
lcore_dma=3Dlcore10@0000:00:04.2-q0,lcore12@0000:00:04.2-q1,lcore13@0000:00= :04.2-q2,lcore14@0000:00:04.2-q3,lcore15@0000:00:04.2-q4,lcore16@0000:00:04= .2-q5,lcore17@0000:00:04.2-q6,lcore18@0000:00:04.2-q7,lcore19@0000:00:04.4-= q0,lcore20@0000:00:04.4-q1,lcore21@0000:00:04.4-q2,lcore22@0000:00:04.4-q3,= lcore23@0000:00:04.4-q4,lcore24@0000:00:04.4-q5,lcore25@0000:00:04.4-q6,lco= re26@0000:00:04.4-q7

becomes:
lcore_dma=3D10@00:04.2-q0,12@00:04.2-q1,13@00:04.2-q2,14@00:04.2-q3,15@00:0= 4.2-q4,16@00:04.2-q5,17@00:04.2-q6,18@00:04.2-q7,19@00:04.4-q0,20@00:04.4-q= 1,21@00:04.4-q2,22@00:04.4-q3,23@00:04.4-q4,24@00:04.4-q5,25@00:04.4-q6,26@= 00:04.4-q7

a reduction from 394 chars to 234 (10 chars per device).

I see what y= ou are suggesting, even though DPDK documentation states 9. EAL parameters =97 Data Plane Development Kit 23.11.0 documentation (dpd= k.org) `<[domai= n:]bus:devid.func>`, omit the domain to `bus:de= vid.func>`. That will reduce the bytes I agree.

However, a better alternative may be to split up the lcore_dma item
entirely, so that we always have one element per line:

lcore_dma0=3Dlcore10@0000:04.2-q0
lcore_dma1=3Dlcore12@0000:04.2-q1
....
lcore_dma15=3Dlcore26@0000:04.4-q7

What is especially good about using this is a solution is that it can be fu= lly
backward compatible and has no ABI issues. If an "lcore_dma=3D" l= ine exists,
we can split it, otherwise look for lcore_dma0, lcore_dma1 etc.

Ok, but this means the test-dma-perf = will need parsing changes and cfgfile library.

As I stated above, the need for really long lines in a config file is a
symptom of a more serious config problem, rather than an issue with the
cfgfile lib itself.

I do not ful= ly agree to this statement, here are my 2 points

  1. current code= is `#ifndef CFG_VALUE_LEN` which means, the user can change the value usin= g compiler flag `-DCFG_VALUE_LEN=3D[user desired value]` as cflags.<= /div>
  2. If not decla= red as CFLAGS configuration value is assumed to be hardened to take only 25= 6

Hence the re= asoning would be `it was not assumed there would be change from 256B was no= t expected or explored. If 256B is the hardlimit then we should not have us= ed #ifndef`.

But +1 for c= hanging the parsing logic.


/Bruce
--_000_MN2PR12MB3085F63F40533093FC9025868284AMN2PR12MB3085namp_--