From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) by dpdk.org (Postfix) with ESMTP id 447C2235 for ; Thu, 3 Aug 2017 18:15:36 +0200 (CEST) Received: by mail-pf0-f177.google.com with SMTP id t86so8155391pfe.2 for ; Thu, 03 Aug 2017 09:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=589k0ZKSotEYLQaNUaeXZRmakj2tgft4aVOIgFW9zRw=; b=ZbFbz7vXkgCAwt1O5SzUdlvZp7gZplpjucwCcLvUuSdGv0zkBtn3aXiTCbJmX5HHjC Y3P2rIDladBpSgtqLtgwr6oaI/ymYNWwB3KF3f17ban1cz/la1v8LIICa9bWDEJ9c8D/ hb4w4GW+gJc+NNSQUbmH8MaZbdF5OuDXBN43VqUY9kT2rTGeKLvXTyQm+/CKFap++qCG oEGTsW0hqHUXKMkQLNNx8yS/cVdwaBQa6D7kC9XKMJoYenFZ7OpJnJ4SG/9X0L0ajYEQ xgJ/cunwGF6e1FP2aKwucMASxU+NrehjBSORVuaaJUFvMFMPf8xXQZfpp0FIglJdBS7I vLiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=589k0ZKSotEYLQaNUaeXZRmakj2tgft4aVOIgFW9zRw=; b=f05+s42AmLnTWnKmC2kmSMpAi64EoMZ3KRTw04g/J8JN3fw3t2kR2RDszBhwL6kXaZ flcb8rc4A8vS3Ecuu06RAm7lL2unPEhBcYIm6hRik1YQzgN9qn8nETOG1RiUpFQbrpuv CC4nfhJl43NuNRnmii+EY6v7ILxDLtBgt8I4FM9z4or81Snj1YhIieHF+bWyvi4cJJqU TsgLHHHFLg7NVMKmeU7yQQ5RZZ6vl13QOSvg8mwYdJtGCMEVBUyv8r3tdKeQPIgfTbkK ke/+07uxsuNVzPve2nAVHiLI0XtIXpzw5sXhm9KSOsN2DZXMqff/Wpvqk4GQqcNPw3ui 7qHQ== X-Gm-Message-State: AIVw113LDjreRhKLTfGZuk+3a30cLxcZAoYf8YZqzTW/JSj97eNvVa5a Xh+hlHGfS2ZsqhvX X-Received: by 10.98.212.92 with SMTP id u28mr2146640pfl.316.1501776935253; Thu, 03 Aug 2017 09:15:35 -0700 (PDT) Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240]) by smtp.gmail.com with ESMTPSA id u12sm12954206pgq.24.2017.08.03.09.15.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 03 Aug 2017 09:15:35 -0700 (PDT) Date: Thu, 3 Aug 2017 09:15:31 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: "Chilikin, Andrey" , "dev@dpdk.org" , "Ananyev, Konstantin" , "Wu, Jingjing" Message-ID: <20170803091531.5902f86c@xeon-e3> In-Reply-To: <20170803132138.GA8732@bricha3-MOBL3.ger.corp.intel.com> References: <20170803132138.GA8732@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:15:36 -0000 On Thu, 3 Aug 2017 14:21:38 +0100 Bruce Richardson 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.