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 39D8843258 for ; Wed, 1 Nov 2023 05:52:18 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 229BB40294; Wed, 1 Nov 2023 05:52:18 +0100 (CET) Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by mails.dpdk.org (Postfix) with ESMTP id 2372D40270; Wed, 1 Nov 2023 05:52:17 +0100 (CET) Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-41b406523fcso45840761cf.2; Tue, 31 Oct 2023 21:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698814336; x=1699419136; 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=iT3yxOUEs1SYmQTwBXcG8zfXnU5Tu6KgXd0CkTB9PUI=; b=TrDF8TzYmbhYEVs2ffijNGqhOBgzx9olXz8tOs2Gn3HTNQMPGkXMUm8Te49Ild2mE3 QPH63JAxu3oX54chmbn3kDQg9FBqu8IjJKy+Jbiu6zaBcw6pbWj/THSPGasSLgeHdt25 Mx6Z+XkB1hA7ArMkaQdzZNlmqZHOzV/tB9dyd6xakOJ9pBlOexz+SZzrLQxITxzsUOkx QE+Si3jOCWg8vlC0Gkf5CGbSrOAv81M1jYGRaeUzAGtPR0j9bEC241Ww7/8h04s/EK3u KAHVY3p7WHRAb4GocjNcANnFzzx2iVhF6LtEvT2bY/pbeoX1NIu6favIkjz65QNicu7j ySkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698814336; x=1699419136; 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=iT3yxOUEs1SYmQTwBXcG8zfXnU5Tu6KgXd0CkTB9PUI=; b=MUE+yK5GfRjwu/RM0JBcepJfdNRPiULNiD12Dk6SSm2GtiH7+b6UVTK2v13d5LrFPZ B2mr/X5oyzVlv+2IE7DZizUJlSXZc3ehOPcn2MERkQEVKStrOxLFPYQkia9ycjQkdIWe v4u33+K4L4U8/DouVewVIR2/tznCK9heu+A+BGue+d8MG6rDo51G0fm5eKVNdndyworp 0GdRYsK2gNU/j5KCw0JXFD+//l0Lv6WHql2TTWJJ/BBHF2r46eyOMzb2py+aINFX7TIs UEy141l4DO0Lq2nhODorFSTeYR4re3thqFfsa1zkGt+5IrQJIUx5BxBMLHyDkkunfXVb 4agg== X-Gm-Message-State: AOJu0YzB7zvzNqh6dAQ6SdUUchoAXufSkekh/JqIECI3v/j155R8BEpI pDJasIm520xgcPDQqjcTdP5R01jS8Yd1nUl0Kuo= X-Google-Smtp-Source: AGHT+IFKEMVpz/q0uY8OPof1WJ+2RQyQ6RLEcm2slSBhKA4S1A+L5DVUkmYKkTDhC0VQm1FVlejVb77y9Xbfs8hKKb0= X-Received: by 2002:ac8:57c2:0:b0:41e:3eef:736d with SMTP id w2-20020ac857c2000000b0041e3eef736dmr16393080qta.5.1698814336470; Tue, 31 Oct 2023 21:52:16 -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 10:21:50 +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 , Thomas Monjalon , "Xia, Chenbo" , nipun.gupta@amd.com 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 Wed, Nov 1, 2023 at 2:14=E2=80=AFAM Bruce Richardson wrote: > > On Wed, Nov 01, 2023 at 12:12:02AM +0530, Jerin Jacob wrote: > > 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 which way we will go would be good for now. I agree to > > > > > having 2 functions in pci common code to enable/disable PASID, bu= t > > > > > we need to have hardcoded PASID cap offset inside these functions > > > > > as well since PASID capability is not exposed 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 i= s > > > > > not 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 functio= ns > > > > > 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 PAS= ID > > > > 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 now. > > > > 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 addin= g > > 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 wi= ll > > change based on the number of capabilities available in PCIe config spa= ce > > for a given device. _if so_, an additional argument for the offset need= s > > to be passed from PMD to common PCI API(I.e it can not be hard-coded in > > common PCI code) > > > > Given these constraints and how late we are in the release cycle, I > therefore suggest we take the driver-specific bug fix for now. DLB seems > the only driver affected right now (and I can confirm the issue having > encountered it myself when running DPDK on Ubuntu 23.04). > > I think a general function is a good thing to have, but it seems that suc= h > a general function should wait until we really can make it generic in the > future. + PCIe maintainers. I will leave this up to @David Marchand / @Thomas as this patch has common code changes and needs to come via main tree. Also in this case, The comment was given very early(Back in June 7) for the same. https://patches.dpdk.org/project/dpdk/patch/20230607210050.107944-1-abdulla= h.sevincer@intel.com/ > > Just my 2c. at this point. > > /Bruce