From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 140963990 for <dev@dpdk.org>; Fri, 2 Sep 2016 12:55:37 +0200 (CEST) Received: by mail-wm0-f54.google.com with SMTP id 1so25046900wmz.1 for <dev@dpdk.org>; Fri, 02 Sep 2016 03:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=3NQE4txMts5sR62e9MqcXjRREZGYEoQvmHg9i6O37Kw=; b=PtdQ+HKRqRJiVZkb5E7YryMUrm7P0CmZy49MvaBs9vov64jfWAGDEzcAqN1/+u3iCv G7/p/gLXr00BhFLMDP+M6pOXdR5BNoWYskUaSRJId32nMinceaDUFNYS7YWnOu40b1DW M0khrCY/MhFGJ7IKTSswMiS/8zEGAFzM69ZYjfaSlUHADPhu/zlGi+LZiCOy2SBWIRZi KoxtMj3fdKzIjJp7j1FVOTVeKHcvr4ITcHxhh4VbgGBR2f1CLWXGnHD3X0z7X1DZF1Qz 5TNXJb29FQ6CpEiqeBWr2dVUYvmYXOp+ZtFEvPSX5Qk+5Rs7rf7zI7cI3gd1TFqoWqUK Wdlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=3NQE4txMts5sR62e9MqcXjRREZGYEoQvmHg9i6O37Kw=; b=lHVmRZG9BfxDjmzm/JETHum1uGePoqV+b8Xt9BnPcNf5zO42opvV+w9pzibQ1SKs/0 J1HsXBrKC2OF/ATWSlUGWUbgWGE6K4OpqKFvtx6uq9OaPCAw8zYwcglRoBNo9OqvFmSc juptMteM8GWQaps6ITihJx4ShMVGknd/hrO4RKARCwo8uZcD6zvfFHGTZYSroHb+IHHX G86NoB82LjFQu5mNH6OqIn1HQDH+CLPWh29nuuSNKoQGDLp58Tk25wCd35hfBHQTbOGC 08Ej2Bb5/O4fEYxJIhbDTifPgkx70zw3+INatfWwFQvm83X7y7X7h5zdKDsbI9aueO7u mBuA== X-Gm-Message-State: AE9vXwMNeAyJc9YHoGhstOtO0g67RGaISHK8QFfE9z+HbT1kAtaP8DeRKmkjiopv4wnguhEG X-Received: by 10.194.43.9 with SMTP id s9mr20102246wjl.46.1472813736649; Fri, 02 Sep 2016 03:55:36 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id pm1sm9852199wjb.40.2016.09.02.03.55.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Sep 2016 03:55:35 -0700 (PDT) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: Stephen Hemminger <stephen@networkplumber.org>, Neil Horman <nhorman@tuxdriver.com>, "Trahe, Fiona" <fiona.trahe@intel.com>, Olivier Matz <olivier.matz@6wind.com> Cc: dev@dpdk.org Date: Fri, 02 Sep 2016 12:55:34 +0200 Message-ID: <6075913.EyZdORayqR@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160901104122.41c131be@xeon-e3> References: <1472217646-26219-1-git-send-email-olivier.matz@6wind.com> <20160901173519.GA11132@hmsreliant.think-freely.org> <20160901104122.41c131be@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 02 Sep 2016 10:55:37 -0000 2016-09-01 10:41, Stephen Hemminger: > Neil Horman <nhorman@tuxdriver.com> wrote: > > On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote: > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz > > > > On 08/31/2016 03:27 PM, Neil Horman wrote: > > > > > Oh, I see, so your list is a colon delimited list of module load sets, where at > > > > > least one set must succeed by loading all modules in its set, but the failure of > > > > > any one set isn't fatal to the process? e.g. a string like this: > > > > > > > > > > uio,igb_uio:vfio,vfio-pci > > > > > > > > > > could be interpreted to mean "I must load (uio AND igb_uio) OR (vfio AND > > > > > vfio-pci). If the evaluation of that statement results in false, then the > > > > > operation fails, otherwise it succedes. > > > > > > > > > > If thats the case, then, apologies, we're on the same page, and this will work > > > > > just fine. > > > > > > > > Yep, that's the idea. > > > > > > > > Colon and commas are the best separators I've thought about, but any > > > > idea to make the syntax clearer is welcome ;) > > > > > > > > Maybe a syntax like is clearer: > > > > "(mod1 & mod2)|(mod3 & mod4)" ? > > > > But it would let the user think that more complex expressions are valid, > > > > like "(mod1 & (mod2 | mod3)) | mod4", which is probably overkill. > > > > > > This RFC seems like a good idea - and something the Intel QuickAssist PMD could benefit from. > > > However the (mod1 & mod2) can handle the QAT case better in my opinion. > > > i.e. > > > as well as needing one of > > > * uio igb_uio > > > * uio uio_pci_generic > > > * vfio vfio-pci > > > QAT PMD also needs one of (depending on which physical device is plugged) > > > * qat_dh895xcc > > > * qat_c62x > > > * qat_c3xxx > > > > > > So the original syntax would result in a very long list of possible variations. > > > What really reflects the dependencies would be > > > ((uio & igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)) & (qat_dh895xcc | qat_c62x | qat_c3xxx) > > > > > Ah, I didn't consider that hardware specifics might create a use case where a > > pmd must have one or more kernel modules available for hw support. Perhaps it > > is worthwhile to automate hardware support - that is to say, any module loading > > script should automatically look at the pci table exported from a pmd, and, if > > found, load any modules that claim support for that device:vendor tuple? Though > > that might break in the case of uio, if there are separate driver modules that > > support native hardware and uio access. > > I ended up writing a script that went the other way. > First look at the hardware and load VFIO if IOMMU is available. > Then look for special driver needed for Xen and HyperV > Lastly fallback to loading igb_uio if no VFIO and PCI device present. > > In other words it is a system not driver issue. That's partly right, yes. But you need some information which are specific to the drivers and we should try to embed them for three usages: - give more info the user (without digging in the doc) - replace info in some external system scripts harder to maintain - prepare for hotplug Some PMDs do not use UIO or VFIO at all, However, I agree that the requirement (uio & igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci) - and even the VFIO noiommu case - could be translated into a simple flag, let's say "generic_device_mapping" (unfortunately "queue_mapping" doesn't exist). The other interesting point from Fiona is to show that this information is device-related (not general for the whole driver). So we should add a device parameter in the macro with the ability to set a wildcard.