From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) by dpdk.org (Postfix) with ESMTP id AA0E156A9 for ; Wed, 10 Feb 2016 16:42:53 +0100 (CET) Received: by mail-vk0-f52.google.com with SMTP id k196so16046257vka.0 for ; Wed, 10 Feb 2016 07:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vH/qt2zVGM4hCHFMEB21DE4lP6zy/S39NaxD26DTERo=; b=B10pAFQBFM4vPs9mdEp0JrrUTb4HwPWQHmIl8jvicTabfKRH87VGm64Vi+i4qD79ou lw6ymDlCcdu6aiwEduHO/g+rMftILzClnUP8L+bPkIEX+L8ruZ//qN1oTiWrhJhT8kVF Pw3AjQyEYJQXOaOXn12umjndXeMYXWJZ2ZdlbRa7wpIaVwoGb2B0w0qzvmx73xdFRqU7 UbWJf/Yg1ekw+8x0SKGkAB/uw3XHFkSzgru9z+5ven7navMZMGQjJo+GzTmasQttvmBB K8VytVtNuAtpwi5buwTKo6H8kkjIfZWjit5LgkPd2FJAMljl2R4V2dCrKxguj3a97qAP /2XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vH/qt2zVGM4hCHFMEB21DE4lP6zy/S39NaxD26DTERo=; b=JFF2WPRbQD+zrT6f4rNLOLz0U/hTulLg7JTBKsJcpw2xNqPy4pf+4SXkM5Ez5/i7yf N9OaXJwBoranirKZrFbkS8vw/5GyXR9D85xbe8gLEnXDXQy8AypxvMtHdF7QZir+GbgC Dz1ICcSMrnrN2aHDo5Xun++Knmsy87FWsRPhP2LFBrOjR9PJJUUDYOCdi+Jmka6XIAUm PXg4TDfJqcdHNXD9iW8p0Btdt08URARilUHML2y5kIo5s/OSn4Xqd3JQ6G5IRxhklfjd 6sy1ROPL2uaFwkij4YhQfLjeCXwesCTeVUyknhlcG0IwGO/WGw1ruy0nN4q/HVhVbiIH ssVQ== X-Gm-Message-State: AG10YOSMolQDSbup8f9ZPUnN3b+ZmFss8l8hYLwHQ7pi/R5TjenvhZ0hK7bwD/wzbJM8YvlW8cwNgaCwzYvmtQ== MIME-Version: 1.0 X-Received: by 10.31.50.202 with SMTP id y193mr30021608vky.48.1455118973099; Wed, 10 Feb 2016 07:42:53 -0800 (PST) Received: by 10.31.134.16 with HTTP; Wed, 10 Feb 2016 07:42:53 -0800 (PST) In-Reply-To: <20160209163731.GA4308@bricha3-MOBL3> References: <1452002675-8919-1-git-send-email-woz@semihalf.com> <1455034146-24036-1-git-send-email-woz@semihalf.com> <20160209163731.GA4308@bricha3-MOBL3> Date: Wed, 10 Feb 2016 16:42:53 +0100 Message-ID: From: =?UTF-8?Q?Wojciech_=C5=BBmuda?= To: Bruce Richardson , bernard.iremonger@intel.com Content-Type: text/plain; charset=UTF-8 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2] af_packet: make the device detachable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 15:42:54 -0000 Hi Bruce, >The use of "deinitialization" sounds awkward Thank you for your interest. I called it deinitialization in opposition to an initialization of a device. As I'm not a native English speaker, I trust your opinion and I'll try to rephrase this. Hi Bernard, >What parameters do you use with --vdev option in testpmd I launch testpmd like this: # ./testpmd -c f -n 4 --vdev 'eth_af_packet0,iface=eth2' -- -i --port-topology=chained Then I can see that af_packet starts: PMD: Initializing pmd_af_packet for eth_af_packet0 PMD: eth_af_packet0: AF_PACKET MMAP parameters: PMD: eth_af_packet0: block size 4096 PMD: eth_af_packet0: block count 256 PMD: eth_af_packet0: frame size 2048 PMD: eth_af_packet0: frame count 512 PMD: eth_af_packet0: creating AF_PACKET-backed ethdev on numa socket When I get to the CLI, I do as follows: Checking link statuses... Port 0 Link Up - speed 10000 Mbps - full-duplex Done testpmd> port stop 0 Stopping ports... Checking link statuses... Port 0 Link Down Done testpmd> port close 0 Closing ports... Done testpmd> port detach 0 Detaching a port... PMD: Closing AF_PACKET ethdev on numa socket 0 Port 'eth_af_packet0' is detached. Now total ports is 0 Done testpmd> In opposition, without the patch detach is impossible: testpmd> port detach 0 Detaching a port... EAL: Driver, cannot detach the device testpmd> Bernard, Bruce, I have a question, if I may. Do you know what is the reason that rte_pmd_af_packet_devinit() is the only non-static device initialization function among all the dpdk drivers? There's even a comment in the rte_eth_af_packet.h: /** * For use by the EAL only. Called as part of EAL init to set up any dummy NICs * configured on command line. */ int rte_pmd_af_packet_devinit(const char *name, const char *params); Despite the comment above, I cannot see this function being called directly anywhere. Is there any reason it is implemented this way? Or should I change the definition to static, as it should be called via proper API functions? Thank you for your time, Wojtek 2016-02-09 17:37 GMT+01:00 Bruce Richardson : > On Tue, Feb 09, 2016 at 05:09:06PM +0100, Wojciech Zmuda wrote: >> Implement rte_pmd_af_packet_devuninit() exposed through struct >> rte_driver.uninit() and set dev_flags to RTE_ETH_DEV_DETACHABLE, >> to allow af_packet device deinitialization with API function >> rte_eth_dev_detach(). This fixes memory leak by freeing memory >> allocated during initialization. >> During device initialization copy device name to ethdev->data to make >> it compatible with rte_eth_dev_allocated(). >> >> Signed-off-by: Wojciech Zmuda >> --- >> v2: >> * Fixed typo and a comment. >> * Added feature to the 2.3 release notes. >> * Free memory allocated for rx and tx queues. >> >> doc/guides/rel_notes/release_2_3.rst | 4 ++++ >> drivers/net/af_packet/rte_eth_af_packet.c | 37 ++++++++++++++++++++++++++++++- >> 2 files changed, 40 insertions(+), 1 deletion(-) >> >> diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst >> index 7945694..4694646 100644 >> --- a/doc/guides/rel_notes/release_2_3.rst >> +++ b/doc/guides/rel_notes/release_2_3.rst >> @@ -39,6 +39,10 @@ This section should contain new features added in this release. Sample format: >> >> Enabled virtio 1.0 support for virtio pmd driver. >> >> +* **Added af_packet driver deinitialization function.** >> + >> + Implemented rte_pmd_af_packet_devuninit() exposed through struct >> + rte_driver.uninit() to allow af_packet device deinitialization with API function. >> > > The use of "deinitialization" sounds awkward, and the overall text maybe could be > made less technical. Maybe talk about "allowing dynamic removal" of af_packet > devices [or even hotplug of them]? > > /Bruce