From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id 06BAC1B571 for ; Wed, 9 Jan 2019 17:52:31 +0100 (CET) Received: by mail-wr1-f65.google.com with SMTP id p4so8394263wrt.7 for ; Wed, 09 Jan 2019 08:52:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:mime-version; bh=lAd876eEjupDBm8f7wsoB9p7BGd38E5R87emzDOsiAg=; b=Hs6UN+YAZwapxygEXmnXaWC4B0DAfXAEVz4CWOBEsInB7Q7Avas49i825bJfFAV3LA GPCWwFUOlSrMu0gd6yEoCcUwy/JXdSBeIr0JaXSns5ULdtr4LjVpQL9w4X70HANKkRXj mIqmMUxza4uq5lC7hVAjbaNtHpzdIBMlAwPsR22FYOVWlvhJIYVg5NeJN2DAUTzr++SK wFy0th2W+HlroW2xW1ZfgKKI1Hw0srKkYheXp7GbEuXKMdE84ckdgnh/LbsAZ8b1D+rn ct2OdcnPdrXdEoOjMc/0sZVvYiCWKG6smM9IhhhaLtlsXAb/1B8+m/PdVmUpJWcpwfP+ VRJg== X-Gm-Message-State: AJcUukfWAUfv04vJSgE+50yC345pJ5Uz5RKEBRzAayPOQ4KXSnz7l3cy pj3xp/aE4dI6tW6zy9hB8HU= X-Google-Smtp-Source: ALg8bN4BQrXcQBew7MqpevUllBlf1qpOcplo4qXo+DDDqC6+hmvFzhh6gfl8fh/Lef99yphAwpG5fg== X-Received: by 2002:a5d:418b:: with SMTP id m11mr5366101wrp.8.1547052750587; Wed, 09 Jan 2019 08:52:30 -0800 (PST) Received: from localhost ([2a01:4b00:f419:6f00:8361:8946:ba2b:d556]) by smtp.gmail.com with ESMTPSA id z14sm43384029wrm.48.2019.01.09.08.52.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 09 Jan 2019 08:52:29 -0800 (PST) Message-ID: <1547052749.6022.69.camel@debian.org> From: Luca Boccassi To: Pavan Nikhilesh Bhagavatula , "thomas@monjalon.net" , Jerin Jacob Kollanukkaran , "yskoh@mellanox.com" Cc: "shahafs@mellanox.com" , "honnappa.nagarahalli@arm.com" , "Gavin.Hu@arm.com" , "tspeier@qti.qualcomm.com" , "dev@dpdk.org" Date: Wed, 09 Jan 2019 16:52:29 +0000 In-Reply-To: <15526e9645417bffc8c0c745b81a2946cd812407.camel@marvell.com> References: <20190109093915.40882-1-yskoh@mellanox.com> <3649611.6SvQ7ZztEu@xps> <6f5a14e478d7c92d1f08a749afac8bb785b3b492.camel@marvell.com> <4346565.rU6Rjy1soH@xps> <043755be57a2f0b30a16d620180bbaa1f5c3144e.camel@marvell.com> <1547048493.6022.65.camel@debian.org> <15526e9645417bffc8c0c745b81a2946cd812407.camel@marvell.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config: change default cache line size for ARMv8 with meson 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, 09 Jan 2019 16:52:31 -0000 On Wed, 2019-01-09 at 16:36 +0000, Pavan Nikhilesh Bhagavatula wrote: > On Wed, 2019-01-09 at 15:41 +0000, Luca Boccassi wrote: > > External Email > >=20 > > ------------------------------------------------------------------- > > --- > > On Wed, 2019-01-09 at 15:34 +0000, Jerin Jacob Kollanukkaran wrote: > > > > > Please check below thread and patch. > > > > >=20 > > > > > http://mails.dpdk.org/archives/dev/2019-January/122676.html > > > > > https://patches.dpdk.org/patch/49477/ > > > > >=20 > > > > > Debian folks are building like this for the _generic_ image. > > > > > What ever works for every distros, I am fine with that. > > > > >=20 > > > > > meson configure -Dmachine=3Ddefault > > > > > meson build > > > > > cd build > > > > > ninja > > > > > ninja install > > > >=20 > > > > I think we agree on the idea of having different configs > > > > for unmodified A72 core and generic build working for all. > > >=20 > > > Yes, I agree. config or some scheme to address the generic and > > > default > > > usecase. > > >=20 > > > > The remaining bits to discuss are: > > > > - do we want to use the armv8 config for unmodified > > > > A72? > > > > - what should be the name of the generic config? > > >=20 > > > If all distros following "meson configure -Dmachine=3Ddefault" > > > scheme > > > why not follow that to make generic image. i.e when > > > machine=3Ddefault > > > set then Cache lize size 128B CL specific stuff be kicked in else > > > it probe the value based on MIDR from sysfs. > > >=20 >=20 > When we are not cross-compiling=C2=A0=C2=A0can read CTR_EL0[1] register > (DminLine) to detect the cacheline size based on the native machine. > This method would satisfy all requirements and we need not maintain a > mapping for cacheline_sizes w.r.t part numbers. >=20 >=20 > [1]=C2=A0 > http://infocenter.arm.com/help/index.jsp?topic=3D/com.arm.doc.100095_00 > 01_02_en/way1382037583047.html >=20 > (newer kernels expose it as a sysfs entry > =C2=A0/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size, we > can > use meson run_command to either run a python program with c byte code > or use cc.run('') to get result directly). Please, not for the machine=3Ddefault case - we need a stable, invariant option that does not depend on the build worker. --=20 Kind regards, Luca Boccassi