From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id 547D21B399 for ; Thu, 14 Feb 2019 11:22:09 +0100 (CET) Received: by mail-wr1-f65.google.com with SMTP id r2so5803361wrv.10 for ; Thu, 14 Feb 2019 02:22:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=dwG6ZHh+pG/MFCsw334QRQ8HEieytws9usegsNKlGPo=; b=GkBOuhD/cG5ddlf0LYXPQYbHPcoJ9k6WSPZCW6MvWuCkxRsHEu6xeB+FiHhYkc19nI /uQ9gW3VhaI6CbKW4goYO3/EX32++cGjX1XFgRfJmVCtOcVN3LIuZDdHWuq7HJTCmzGW H60AU6H25lfJ3LN0cCCejiTU5inky/co1dlZF81tf3bezZWAUokFl/YLD+gFrnQipNdY wVdRhSHIs6uthmbqTryoUKvqqGefbGwhvu0ERjC9HPqeHtGoWn3KihRUbxEQz24/rG4s 9Xmm5d+8FWcJU34Tl3byJ6Vd3MlxDFPRUExSmOMnZKE6Mw5RgYbQxovxA3wK2EjW4aG5 MF3A== 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:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=dwG6ZHh+pG/MFCsw334QRQ8HEieytws9usegsNKlGPo=; b=itOrCp+vJ9KV6B+ZtImccgNFp+ZMNK0jxoVxu2qKTAQ84qafjVxrrVar0Z4PA+twuV iXhXGOhVAhrnzEnEnL55Tc7MQlzuVvI5YXOJ0AYMhAlBbElweGoL9eB7E2UaTxdDBtiX LK6NEZXdJ7kbF7tSakKAbl0zRmziP0mK/E2JTiWNyEjUAMUO0J3F46kGSTpjundwhy2P hxoNDr+R7cKCRgoB1G9vMrKekiBDAZY0FhFOJwaOeiCATRgvk9NaoGD8CKRivLmWtlMj 87GR5xSM5zL0pIctDJ3DO+0YjEFy/ZwE0kOVNwHzT3mMsspm3sHMhTWutlMEW5IMPgSX TWOA== X-Gm-Message-State: AHQUAuYXl0386K8KFCMINeHiW3fUePRv8NgIAAj5jDL3zdsMT91Kes3h UXbaMXLcbvaIXNu2YNaxaItTdnkp9/w= X-Google-Smtp-Source: AHgI3IaSY9y28cq8L15deZ0uYWX4n4bXNQDIv3/ZgN0s2IJmT+mtDV9zD6kAHL3pPnd+iEVuKddrmQ== X-Received: by 2002:a05:6000:6:: with SMTP id h6mr2188055wrx.68.1550139728714; Thu, 14 Feb 2019 02:22:08 -0800 (PST) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id y1sm2303707wrh.65.2019.02.14.02.22.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Feb 2019 02:22:07 -0800 (PST) Date: Thu, 14 Feb 2019 11:21:45 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Shahaf Shuler Cc: "anatoly.burakov@intel.com" , Yongseok Koh , Thomas Monjalon , "ferruh.yigit@intel.com" , "nhorman@tuxdriver.com" , "dev@dpdk.org" Message-ID: <20190214102145.hyveguazu3f64sji@bidouze.vm.6wind.com> References: <20190213113504.7aoc7myuacpmqo2b@bidouze.vm.6wind.com> <20190213114425.gsmqftnmakk4u3pj@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH 5/6] net/mlx5: support PCI device DMA map and unmap 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, 14 Feb 2019 10:22:09 -0000 On Wed, Feb 13, 2019 at 07:11:35PM +0000, Shahaf Shuler wrote: > Wednesday, February 13, 2019 1:44 PM, Gaëtan Rivet: > > Subject: Re: [PATCH 5/6] net/mlx5: support PCI device DMA map and unmap > > > > On Wed, Feb 13, 2019 at 12:35:04PM +0100, Gaëtan Rivet wrote: > > > On Wed, Feb 13, 2019 at 11:10:25AM +0200, Shahaf Shuler wrote: > > > > The implementation reuses the external memory registration work done > > [..] > > > > > + > > > > + /** > > > > + * We really need to iterate all eth devices regardless of > > > > + * their owner. > > > > + */ > > > > + while (port_id < RTE_MAX_ETHPORTS) { > > > > + port_id = rte_eth_find_next(port_id); > > > > + if (port_id >= RTE_MAX_ETHPORTS) > > > > + break; > > > > + dev = &rte_eth_devices[port_id]; > > > > + drv_name = dev->device->driver->name; > > > > + if (!strncmp(drv_name, MLX5_DRIVER_NAME, > > > > + sizeof(MLX5_DRIVER_NAME) + 1) && > > > > + pdev == RTE_DEV_TO_PCI(dev->device)) { > > > > + /* found the PCI device. */ > > > > + return dev; > > > > + } > > > > + } > > > > + return NULL; > > > > +} > > > > > > Might I interest you in the new API? > > Good suggestion, will have a look on it in depth. > > > > > > > { > > > struct rte_dev_iterator it; > > > struct rte_device *dev; > > > > > > RTE_DEV_FOREACH(dev, "class=eth", &it) > > > if (dev == &pdev->device) > > > return it.class_device; > > > return NULL; > > > } > > > > > > > On that note, this could be in the PCI bus instead? > > We can put it on the PCI bus, but it would mean the PCI bus will not be device agnostic. > Currently, I couldn't find any reference to eth_dev on the PCI bus, besides a single macro which convert to pci device that doesn't really do type checks. > > Having it in, would mean the PCI will need start to distinguish between ethdev, crypto dev and what ever devices exists on its bus. > I think it's worth thinking about it. It can stay class-agnostic: void * rte_pci_device_class(struct rte_pci_device *pdev, const char *class) { char devstr[15+strlen(class)]; struct rte_dev_iterator it; struct rte_device *dev; snprintf(devstr, sizeof(devstr), "bus=pci/class=%s", class); RTE_DEV_FOREACH(dev, devstr, &it) if (dev == &pdev->device) return it.class_device; return NULL; } (not a fan of the stack VLA but whatever.) then: eth_dev = rte_pci_device_class(pdev, "eth"); Whichever type of device could be returned. Only limit is that you have to know beforehand what is the device type of the PCI device you are querying about, but that's necessary anyway. And if it was instead a crypto dev, it would return NULL. -- Gaëtan Rivet 6WIND