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 3F7D143256 for ; Tue, 31 Oct 2023 19:42:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 34BE040691; Tue, 31 Oct 2023 19:42:31 +0100 (CET) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by mails.dpdk.org (Postfix) with ESMTP id 6FAC540285; Tue, 31 Oct 2023 19:42:29 +0100 (CET) Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-41b406523fcso42959231cf.2; Tue, 31 Oct 2023 11:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698777749; x=1699382549; 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=ugLcMouErhoJwAgJLScTrFvgf88oNbObNyCi25PrnWo=; b=V27jGPyafK8lIgz3vGrPU9Ys+6NtpvXFQvO7oJI06k5F5bO2J2D9totMDb2oxpb7qS 3eunmAWH5Tn9x2Wu9rGvPW3/dtHN4Gxv292DE8UmiSUbdQdrH7WyeuPtituSeE67SSd5 mw5tKbTkFlEaND9A3RQXsMTnvz6o4K8YEe3AnOTLepnap9qhwvKEWgXHrMVR1+eT4qcg 1rjJMu7iVV+M68j/58xjoVmGYbBAxpPVFa/ZgMrM3wmp+hPUVvJPfwOsLqH0KCzNsho2 nvNMURTTTaugAItLfRRux0g5MaTycNRhxJEiGyQ0pVVBzYPSCRy0usx9//oVm+wPZ738 Ph2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698777749; x=1699382549; 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=ugLcMouErhoJwAgJLScTrFvgf88oNbObNyCi25PrnWo=; b=C7uq+2tY7gg4vTxMeVefiqF8ha8o1FZDfAVNGtr6uYHrO32ADtseqZ/DhaSuNABvne B92SH9ZZOzJngZQTzhI8NsxSlS0IAtKeBTOupLh97rW/LREcD+5cSq3kN9wxaqQWmLAc xkX8kboQQ7ZtRosEGzIm53C3RjfyZzQxGXcLfK4ZHO5GWtEWh5TDEReMhHLW0wJYzDFM nDHoVMP87dzAq8JINRYsClM+JQjvnYnXOVjriVcZCXgnpDMswZFVYWkwYTTVx2/2w7zC 5hE6XhBzLjROGmbgvibIFZShSfNgn2M6Wq3bbtq35mITzNLmLkaEH2fcqHQc6eu3f4Qt js9g== X-Gm-Message-State: AOJu0YyJ4QYjZeG7tTzLdcuQdPq6Y2S9EP6//51bbuoSzMYneQ7fTA+5 iGgZNGjNSU7Rca/xjP0zUHLYwpNeo43Y6aD0v70= X-Google-Smtp-Source: AGHT+IFW8q/4oBn8HAZArCLSCfEZfiwJUgE/uTKiFjf/rkCJsj8fa6o0a3ZWcRBDa9Efc4KdAIvwuR2NiHibZd5jsF0= X-Received: by 2002:ac8:4e88:0:b0:419:8f42:8c45 with SMTP id 8-20020ac84e88000000b004198f428c45mr17996288qtp.8.1698777748755; Tue, 31 Oct 2023 11:42:28 -0700 (PDT) MIME-Version: 1.0 References: <20230607210050.107944-1-abdullah.sevincer@intel.com> <20231030211244.2516043-1-abdullah.sevincer@intel.com> In-Reply-To: From: Jerin Jacob Date: Wed, 1 Nov 2023 00:12:02 +0530 Message-ID: Subject: Re: [PATCH v3] event/dlb2: fix disable PASID for kernel 6.2 To: Bruce Richardson Cc: "Sevincer, Abdullah" , "dev@dpdk.org" , "jerinj@marvell.com" , "Chen, Mike Ximing" , "stable@dpdk.org" , David Marchand Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Tue, Oct 31, 2023 at 10:45=E2=80=AFPM Bruce Richardson wrote: > > On Tue, Oct 31, 2023 at 10:36:04PM +0530, Jerin Jacob wrote: > > On Tue, Oct 31, 2023 at 8:43=E2=80=AFPM Sevincer, Abdullah > > wrote: > > > > > > > > > > +This patch can be splited as two, > > > > +1) Generic PCIe function to enable/disable PASID > > > > +2) Call generic function to disable PASID in drivers/event/dlb2/. = Also mention which Linux kernel commit is introducing this issue in the git= commit log. > > > > > > Hi Jerrin, > > > I think I need to provide more information here, then we can decide w= hich way we will go would be good for now. I agree to having 2 functions in= pci common > > > code to enable/disable PASID, but we need to have hardcoded PASID cap= offset inside these functions as well since PASID capability is not expose= d to user. Hence, to be more specific > > > main reason to have hardcoded PASID is, rte_pci_find_ext_capability()= function to retrieve the offset returns '0' since PASID is not exposed to = user yet. > > > > > > We can see this is vfio_pci_config.c in kernel code where PASID is no= t exposed to user. > > > [PCI_EXT_CAP_ID_PASID] =3D 0, /* not yet */ > > > > > > So if it is okay to go with hardcoded offset now in these functions I= will move the implementation to pci_common file. > > > > I would suggest, add argument option to API whether to probe the > > capability or not? - 0 means probe and- non zero means specific PASID > > cap offset till Linux VFIO is exposing it. > > That doesn't seem particularly useful to me. The calling-API in the DPDK > PMD (assuming it's PMD who use this), is no more likely to know whether > probing will work. Therefore, I think we just hard-code the offset for no= w. I think, there are three things here 1) Whether to have common API for dealing with generic function like enabling PASID or not? - I think, we are in agreement to have common public function(Implementation could be hard-coded or probe) 2) Since it is public PCIe API, I thought of adding probing in API as it is just LINUX limitation now. No strong opinion on inclusion of probe in on this as Linux is main EAL which supports PCIe now. 3) Since it is PCIe capability, In my understanding the offset will change based on the number of capabilities available in PCIe config space for a given device. _if so_, an additional argument for the offset needs to be passed from PMD to common PCI API(I.e it can not be hard-coded in common PCI code) > We can decide what the best approach is later on once kernel actually > exposes the value to users. Only then will we know if it's possible to > detect that exposure or not. > > /Bruce