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 9538645B99; Tue, 22 Oct 2024 04:47:09 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 87A7B402BC; Tue, 22 Oct 2024 04:47:07 +0200 (CEST) Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by mails.dpdk.org (Postfix) with ESMTP id F323740295 for ; Tue, 22 Oct 2024 04:47:06 +0200 (CEST) Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-460b04e4b1cso27779991cf.2 for ; Mon, 21 Oct 2024 19:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729565226; x=1730170026; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OXgSPNRHyUyrKoA6KjSaqmbnz3Xbp+pOZBdnSQuqyXA=; b=EAgjWi9PGM82iOZaXBgdZlfo6Du9kInMNNq9cm4pEpvdvIIQi9VoFx6aWMiAURzGff 9/QAOIAaZVCjzXUKGtwfU70WA734NkFQyQHP4fI3eNv8zEHcXxarSx7s6G0m2P0SH/1Y AEj/Ysg6vN9s8d6TbHZf0JfKk+OdO4Kv/EPFOKUMWtRsej6pZ01BaR/dg2qzr90FE7XJ PUx36NSKf+5e/QEjHs27jHfuo/pKj7tvZB6zLvMvQSP3KpN9v7+HKSK69Oq255KNrrIE 7/we6c34fGwRb/kciA8fTDvgOiHQbhh4eu0tyLvV/FukmI3IT8UpE0JGOYrXgpetk51B /B9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729565226; x=1730170026; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OXgSPNRHyUyrKoA6KjSaqmbnz3Xbp+pOZBdnSQuqyXA=; b=I42KyCBLJWzhwzs0v66XUXkdmvhy0YZHUe9tk/o6WtcC7HQBQGEh4EAu2nwDwG1X8v 9pF7d7obQX2N+eMIJwjM67oRwbK9USvglWwi2HQEKxSjSvmiUkMkdb1Nfy+I0e2S4CGk PFBhwXu08RZZqyPJOOpdwP5OIaQo4WjvbZqijouHhlt/XjiZBBEnKJeU79dWcqF8x71o Q14sT2ttrKwrp8MzwhBuGR6xPoFjVt1C5lZkOH5454t1iKXmYMqOHptla7WNizOf01h9 2dnT6o7wM0UUqs6hg3Q0CuRCn701zFjFXfgjtgFi+C384oDuO+Nhz3K/TGYNKNlF8wgQ xqfA== X-Forwarded-Encrypted: i=1; AJvYcCXziyK/cwdmyJb5wab0Lj9SgdF/gkv8Tg3kNLu+MlREs626lIo2T3+5zdXgLKZf+z3kJtk=@dpdk.org X-Gm-Message-State: AOJu0YzsXbY/vd73haVOa/XsJQkfHP+cqHd8Jc5n3u72iUW8E07PlOBN q4ICWb5/dxr0jjo3f74r55Eu0VFfnjRdEJi16OSlLxK7D7tWLGxHZLRaThCd/QdU6TRckstRH0U 5zYKPkm+5ZEWM4ebsFTS3WIhHO74= X-Google-Smtp-Source: AGHT+IFpIBc/sd2Iy0pTcRu2ssrBLkewQUvQOphpfl+QsNRZdkE5ZkNOC8PWQeh+v4WfHXD4xftq3K9sXcGDpvSf6oA= X-Received: by 2002:a05:622a:15d1:b0:458:2607:d5a7 with SMTP id d75a77b69052e-460aee2ba0emr220051771cf.43.1729565226241; Mon, 21 Oct 2024 19:47:06 -0700 (PDT) MIME-Version: 1.0 References: <20241008105415.1026962-1-gakhil@marvell.com> <20241008184915.1356089-1-gakhil@marvell.com> <20241008184915.1356089-4-gakhil@marvell.com> <86546386.BzKH3j3Lxt@thomas> In-Reply-To: <86546386.BzKH3j3Lxt@thomas> From: Jerin Jacob Date: Tue, 22 Oct 2024 08:16:39 +0530 Message-ID: Subject: Re: [PATCH v3 3/9] raw/cnxk_rvu_lf: add PMD API to get BAR addresses To: Thomas Monjalon Cc: Akhil Goyal , dev@dpdk.org, david.marchand@redhat.com, jerinj@marvell.com, hkalra@marvell.com, Stephen Hemminger , Bruce Richardson , Hemant Agrawal , Sachin Saxena , Ferruh Yigit Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Tue, Oct 22, 2024 at 3:00=E2=80=AFAM Thomas Monjalon wrote: > > 08/10/2024 20:49, Akhil Goyal: > > Added rte_pmd_rvu_lf_bar_get() API to get BAR address > > for application to configure hardware. > > In my opinion, we should not return PCI BAR addresses to an application. > We should make an effort to have all theses details managed in the driver= . > Giving this level of access to an app is a door we should probably not op= en. I agree with this in the traditional application laying context. Typical layering is "driver" -> "device class like ethdev" ->application. In this case, This raw driver is a proprietary 5G PCIe device where the DPDK does not have a subsystem for that. So application is layered to have "Hardware abstraction library" and "Application" i.e "cnxk lf raw driver" -> "Hardware abstraction library using the BAR address" -> "Real Application". The real application is taking only to the Hardware abstraction library. The rational to NOT pull "Hardware abstraction library using the BAR address" to DPDK are -Yet another 200K of driver C++ code which does not make sense to keep in dpdk.org -It can not implemenent any of the current subsystems In this context, let me know what you think?