From: "Roberts, Lee A." <lee.roberts@hpe.com>
To: "Tan, Jianfeng" <jianfeng.tan@intel.com>,
Ferruh Yigit <ferruh.yigit@intel.com>,
Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"stable@dpdk.org" <stable@dpdk.org>,
Jingjing Wu <jingjing.wu@intel.com>,
Shijith Thotton <shijith.thotton@caviumnetworks.com>,
Gregory Etelson <gregory@weka.io>,
Harish Patil <harish.patil@cavium.com>,
George Prekas <george.prekas@epfl.ch>,
Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>,
Rasesh Mody <rasesh.mody@cavium.com>
Subject: Re: [dpdk-dev] [PATCH v2] igb_uio: add config option to control reset
Date: Fri, 3 Nov 2017 19:42:45 +0000 [thread overview]
Message-ID: <TU4PR8401MB0687C334FCD16962578F0029E55D0@TU4PR8401MB0687.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <bef1f5ac-adf9-105a-388b-e35a24dc0577@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tan, Jianfeng
> Sent: Thursday, November 02, 2017 8:57 PM
> To: Ferruh Yigit <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: dev@dpdk.org; stable@dpdk.org; Jingjing Wu <jingjing.wu@intel.com>; Shijith Thotton
> <shijith.thotton@caviumnetworks.com>; Gregory Etelson <gregory@weka.io>; Harish Patil
> <harish.patil@cavium.com>; George Prekas <george.prekas@epfl.ch>; Sergio Gonzalez Monroy
> <sergio.gonzalez.monroy@intel.com>; Rasesh Mody <rasesh.mody@cavium.com>
> Subject: Re: [dpdk-dev] [PATCH v2] igb_uio: add config option to control reset
>
>
>
> On 11/3/2017 8:51 AM, Ferruh Yigit wrote:
> > Adding a compile time configuration option to control device reset done
> > during DPDK application exit.
> >
> > Config option is CONFIG_RTE_EAL_IGB_UIO_RESET and enabled by default,
> > so by default reset will happen. Having this reset is safer to be sure
> > device left in a proper case.
> >
> > But for special cases [1] it is possible to disable the config option
> > to prevent the device reset.
> >
> > [1]
> > http://dpdk.org/ml/archives/dev/2017-November/080927.html
> >
> > Fixes: b58eedfc7dd5 ("igb_uio: issue FLR during open and release of device file")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
> Realize that we do have a pci_clear_master() in the release() to disable
> the DMA from device until the next open() will enable the DMA again .
> Here is my:
>
> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
>
> Thanks,
> Jianfeng
>
> > ---
> > Cc: Jianfeng Tan <jianfeng.tan@intel.com>
> > Cc: Jingjing Wu <jingjing.wu@intel.com>
> > Cc: Shijith Thotton <shijith.thotton@caviumnetworks.com>
> > Cc: Gregory Etelson <gregory@weka.io>
> > Cc: Harish Patil <harish.patil@cavium.com>
> > Cc: George Prekas <george.prekas@epfl.ch>
> > Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> > Cc: Rasesh Mody <rasesh.mody@cavium.com>
> >
> > v2:
> > * fix typo in commit log
> > ---
> > config/common_base | 1 +
> > config/common_linuxapp | 1 +
> > lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 2 ++
> > 3 files changed, 4 insertions(+)
> >
> > diff --git a/config/common_base b/config/common_base
> > index 82ee75456..2a9947420 100644
> > --- a/config/common_base
> > +++ b/config/common_base
> > @@ -102,6 +102,7 @@ CONFIG_RTE_LIBEAL_USE_HPET=n
> > CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
> > CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
> > CONFIG_RTE_EAL_IGB_UIO=n
> > +CONFIG_RTE_EAL_IGB_UIO_RESET=n
> > CONFIG_RTE_EAL_VFIO=n
> > CONFIG_RTE_MALLOC_DEBUG=n
> > CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
> > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > index 74c7d64ec..b3a602909 100644
> > --- a/config/common_linuxapp
> > +++ b/config/common_linuxapp
> > @@ -37,6 +37,7 @@ CONFIG_RTE_EXEC_ENV_LINUXAPP=y
> >
> > CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
> > CONFIG_RTE_EAL_IGB_UIO=y
> > +CONFIG_RTE_EAL_IGB_UIO_RESET=y
> > CONFIG_RTE_EAL_VFIO=y
> > CONFIG_RTE_KNI_KMOD=y
> > CONFIG_RTE_LIBRTE_KNI=y
> > diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > index fd320d87d..0325722c0 100644
> > --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > @@ -360,7 +360,9 @@ igbuio_pci_release(struct uio_info *info, struct inode *inode)
> > /* stop the device from further DMA */
> > pci_clear_master(dev);
> >
> > +#ifdef RTE_EAL_IGB_UIO_RESET
> > pci_reset_function(dev);
> > +#endif
> >
> > return 0;
> > }
A compile time configuration option makes life very difficult for application providers.
Consider the case where an application such as Open vSwitch with DPDK support is being provided
with a Linux distribution. One would want the Open vSwitch binary to support as many vendor NICs
as possible---without the need to recompile. With a change such as this, one would need to have
different versions of the kernel igb_uio module to support different NICs.
The Linux kernel is already aware of, and provides work-arounds for, various PCI quirks.
For example, see linux/drivers/pci/quirks.c (http://elixir.free-electrons.com/linux/latest/source/drivers/pci/quirks.c).
At this point in igb_uio.c, one is aware of the struct pci_dev "dev" for the device in question.
Access to the vendor and device information should be simple:
struct pci_dev {
struct list_head bus_list; /* node in per-bus list */
struct pci_bus *bus; /* bus this device is on */
struct pci_bus *subordinate; /* bus this device bridges to */
void *sysdata; /* hook for sys-specific extension */
struct proc_dir_entry *procent; /* device entry in /proc/bus/pci */
struct pci_slot *slot; /* Physical slot this device is in */
unsigned int devfn; /* encoded device & function index */
unsigned short vendor;
unsigned short device;
unsigned short subsystem_vendor;
unsigned short subsystem_device;
...
One could imagine using logic to implement corresponding PCI quirks that can be evaluated
at runtime. For example (in pseudocode),
if not (vendor = "Cavium" and device = "bnx2x")
then pci_reset_function(dev);
There are other possible implementations. If there are enough quirks, one might have action
functions defined---and a table of function pointers associated with each PMD to select the
proper action.
- Lee Roberts
next prev parent reply other threads:[~2017-11-03 19:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-03 0:30 [dpdk-dev] [PATCH] " Ferruh Yigit
2017-11-03 0:51 ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
2017-11-03 2:57 ` Tan, Jianfeng
2017-11-03 19:42 ` Roberts, Lee A. [this message]
2017-11-03 22:03 ` Ferruh Yigit
2017-11-04 10:08 ` Stephen Hemminger
2017-11-06 18:41 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=TU4PR8401MB0687C334FCD16962578F0029E55D0@TU4PR8401MB0687.NAMPRD84.PROD.OUTLOOK.COM \
--to=lee.roberts@hpe.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=george.prekas@epfl.ch \
--cc=gregory@weka.io \
--cc=harish.patil@cavium.com \
--cc=jianfeng.tan@intel.com \
--cc=jingjing.wu@intel.com \
--cc=rasesh.mody@cavium.com \
--cc=sergio.gonzalez.monroy@intel.com \
--cc=shijith.thotton@caviumnetworks.com \
--cc=stable@dpdk.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).