From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 0CA3C2986 for <dev@dpdk.org>; Thu, 3 Aug 2017 21:53:47 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A13802080C; Thu, 3 Aug 2017 15:53:46 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 03 Aug 2017 15:53:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=50d7m6QZKhoVQFD XMPzlvJ2whv4qGjdim4sH7DmAq2Y=; b=a6Y67f/BQYDnB0MoSNYvGs+EiQ5DlhO fWPJWKfUSgla8AkigLq/WEus+rDUFnjwspaKAzVzpUdqvYq0KRI6yAnfLmZHwqNQ 8Kz8Bx/Vcb8It7Nd69xp/j7a64/yFKJm46tKAOf5LwH3LmgodSs9pU/K7OkGb/9m 4itws2wJ+rXk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=50d7m6QZKhoVQFDXMPzlvJ2whv4qGjdim4sH7DmAq2Y=; b=loPMrtbh Dtw9Vjh1D56xaNS5zre1Xh3n0Q+w3aw+EuZVd1W2JXDpYstGtPvTM8O/YNtLF2AT jiudsJ+I4JCPahL68UBI2uKCZ7Hkb8kQyMjbeoF1k1Cnmp5QWYL4gFXrgtsTRXm9 87JGGO7XFkrqIW1wPgwVE3OAkqDLuTMXe147ep5yIanXgmb/HaV2d2GQ1abcEKm3 jbJxzAHdUocYZfekSNG4Zr0BLiylzfzPqO/ZP5gyQqYNHkCTFdUhhben82X92xoT ygO6nYk82vNWIR62SC4EeLUqw9y2or3b3AZQzP6NiSOBY8EwLpi2m9TLcMSuO4KG sQSBv6M8NjxSDg== X-ME-Sender: <xms:Sn-DWTuz6xrImVJkt2KJyyi6xRWPwYtwaeYV-fn5CQjbPAciyXuJPQ> X-Sasl-enc: Wov2FUtBgcuNyri26ILz/RluCXeSwVYOCXvJd27obOEL 1501790026 Received: from xps.localnet (196.114.118.80.rev.sfr.net [80.118.114.196]) by mail.messagingengine.com (Postfix) with ESMTPA id 2DFA724515; Thu, 3 Aug 2017 15:53:46 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: dev@dpdk.org Cc: Stephen Hemminger <stephen@networkplumber.org>, Bruce Richardson <bruce.richardson@intel.com>, "Chilikin, Andrey" <andrey.chilikin@intel.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "Wu, Jingjing" <jingjing.wu@intel.com> Date: Thu, 03 Aug 2017 21:53:45 +0200 Message-ID: <1581480.IJArXVfUmc@xps> In-Reply-To: <20170803091531.5902f86c@xeon-e3> References: <AAC06825A3B29643AF5372F5E0DDF0538DBC372E@IRSMSX106.ger.corp.intel.com> <20170803132138.GA8732@bricha3-MOBL3.ger.corp.intel.com> <20170803091531.5902f86c@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC] ethdev: add ioctl-like API to control device specific features X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <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: Thu, 03 Aug 2017 19:53:47 -0000 03/08/2017 18:15, Stephen Hemminger: > On Thu, 3 Aug 2017 14:21:38 +0100 > Bruce Richardson <bruce.richardson@intel.com> wrote: > > > On Thu, Aug 03, 2017 at 01:21:35PM +0100, Chilikin, Andrey wrote: > > > To control some device-specific features public device-specific functions > > > rte_pmd_*.h are used. > > > > > > But this solution requires applications to distinguish devices at runtime > > > and, depending on the device type, call corresponding device-specific > > > functions even if functions' parameters are the same. > > > > > > IOCTL-like API can be added to ethdev instead of public device-specific > > > functions to address the following: > > > > > > * allow more usable support of features across a range of NIC from > > > one vendor, but not others > > > * allow features to be implemented by multiple NIC drivers without > > > relying on a critical mass to get the functionality in ethdev > > > * there are a large number of possible device specific functions, and > > > creating individual APIs for each one is not a good solution > > > * IOCTLs are a proven method for solving this problem in other areas, > > > i.e. OS kernels. > > > > > > Control requests for this API will be globally defined at ethdev level, so > > > an application will use single API call to control different devices from > > > one/multiple vendors. > > > > > > API call may look like as a classic ioctl with an extra parameter for > > > argument length for better sanity checks: > > > > > > int > > > rte_eth_dev_ioctl(uint16_t port, uint64_t ctl, void *argp, > > > unsigned arg_length); > > > > > > Regards, > > > Andrey > > > > I think we need to start putting in IOCTLs for ethdevs, much as I hate > > to admit it, since I dislike IOCTLs and other functions with opaque > > arguments! Having driver specific functions I don't think will scale > > well as each vendor tries to expose as much of their driver specific > > functionality as possible. > > > > One other additional example: I discovered just this week another issue > > with driver specific functions and testpmd, when I was working on the > > meson build rework. > > > > * With shared libraries, when we do "ninja install" we want our DPDK > > libs moved to e.g. /usr/local/lib, but the drivers moved to a separate > > driver folder, so that they can be automatically loaded from that > > single location by DPDK apps [== CONFIG_RTE_EAL_PMD_PATH]. > > * However, testpmd, as well as using the drivers as plugins, uses > > driver-specific functions, which means that it explicitly links > > against the pmd .so files. > > * Those driver .so files are not in with the other libraries, so ld.so > > does not find the pmd, and the installed testpmd fails to run due to > > missing library dependencies. > > * The workaround is to add the drivers path to the ld load path, but we > > should not require ld library path changes just to get DPDK apps to > > work. > > > > Using ioctls instead of driver-specific functions would solve this. > > > > My 2c. > > My 2c. No. > > Short answer: > Ioctl's were a bad idea in Unix (per Dennis Ritchie et al) and are now > despised by Linux kernel developers. They provide an unstructured, unsecured, > back door for device driver abuse. Try to get a new driver in Linux with > a unique ioctl, and it will be hard to get accepted. > > Long answer: > So far every device specific feature has fit into ethdev model. Doing ioctl > is admitting "it is too hard to be general, we need need an out". For something > that is a flag, it should fit into existing config model; ignoring silly ABI constraints. > For a real feature (think flow direction), we want a first class API for that. > For a wart, then devargs will do. > > Give a good example of something that should be an ioctl. Don't build the > API first and then let it get cluttered. I agree with Stephen. And please do not forget that ioctl still requires an API: the argument that you put in ioctl is the API of the feature. So it is the same thing as defining a new function. The real debate is to decide if we want to continue adding more control path features in DPDK or focus on Rx/Tx. But this discussion would be better lead with some examples/requests.