From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by dpdk.org (Postfix) with ESMTP id A54F39DE for ; Fri, 6 Dec 2013 07:21:03 +0100 (CET) Received: by mail-pd0-f176.google.com with SMTP id w10so461794pde.7 for ; Thu, 05 Dec 2013 22:22:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CDOPsN0J6cWxc4jgwCu1noAux51lAJTOJfpI8pd8x4Q=; b=fGyaTz1ddcUeZ7ry/x4BlG7s0piVOVcA/s3evrLaSU+e/Hjf1XgBp6Vm4xeU3UUYYx mmZ1dRSaGmiI8dDHZJvOUi0UObn0piKOcXuI7ndpqJGNCVPq9OA1Ck6BwHPk8c6P00bo Wu+A3tmoa+rhp0FY7UdQXVqf3LDdqyjLJx1pvCcWWWLrEBxe6Fp41nicyBlFPJNvQIeU fP1nmU3EL03RwW54jQ0AYq3kAwBbv3wP3faAejNV5K1sIPaJbf0qX6roZeKySY/sCMeQ XpE2N4LyLvtqJna2zOJaCz/ATjB7TVs/WE3NnGLgDFVxKMjY6LSSqbybWQDImEmtZmek J58w== X-Gm-Message-State: ALoCoQmwZBb/zKVfRFs9yeEHlttvzkXPB2vwf2AAcRrVF2q/AB5BirAFpVTZ3SqA70b62DhD7Ofx X-Received: by 10.68.6.99 with SMTP id z3mr2101627pbz.114.1386310926086; Thu, 05 Dec 2013 22:22:06 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by mx.google.com with ESMTPSA id iu7sm149130555pbc.45.2013.12.05.22.22.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 22:22:05 -0800 (PST) Message-ID: <52A16D0E.2080909@igel.co.jp> Date: Fri, 06 Dec 2013 15:22:06 +0900 From: "Tetsuya.Mukawa" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Richardson, Bruce" , "dev@dpdk.org" References: <529474D5.80306@igel.co.jp> <59AF69C657FD0841A61C55336867B5B01A9778E3@IRSMSX103.ger.corp.intel.com> <52954F27.3040706@igel.co.jp> <59AF69C657FD0841A61C55336867B5B01A9781D3@IRSMSX103.ger.corp.intel.com> In-Reply-To: <59AF69C657FD0841A61C55336867B5B01A9781D3@IRSMSX103.ger.corp.intel.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] How to know corresponding device from port number 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: Fri, 06 Dec 2013 06:21:04 -0000 (2013/11/28 19:46), Richardson, Bruce wrote: >> If someone wants to implement forwarding application that receives >> packets from ETH_A and send those to ETH_B. >> Also above application is split to 3 processes like following. >> [ETH_A]-->Process_A --> [Ring_A] --> Process_B --> [Ring_B] --> Process_C -- >>> [ETH_B] (All 3 processes are implemented using PMD) >> At present, to implement Process_B might be difficult or tricky because ring >> can't be distinguished. >> >> I guess all virtual eth device like ring and pcap should have MAC address. >> And It should be possible to specify MAC address from command line. >> If so, DPDK application can distinguish all ports using MAC address even if >> port corresponds virtual eth device. > [BR] Actually, the way the ring pmd is implemented is designed to take account of this multi-process scenario in a slightly different way. > > Firstly, the ethernet device numbers used are always per-process, which is why in the multiprocess case, we still do a load of the ethernet drivers and a pci probe on initialization of secondary processes. Any ring PMDs created by passing EAL parameters to a process are therefore local to that process alone. To use the ring-based PMD to exchange packets between two processes, the APIs of the ring PMD should be used directly by the app, instead of via the EAL commandline. The rings should be directly created in the app, e.g. in process A, using rte_ring_create(), and then, if you need a PMD interface to the ring, you call the rte_eth_from_rings() API. Then in process B, you use rte_ring_lookup() to get the pointer to the ring(s) you wish to use, and again call rte_eth_from_ring() to similarly wrap that into an eth_dev structure. > > (Now, it's also worth noting that you may pay a very small performance penalty for not using the ring APIs directly, since the ring enqueue and dequeue functions are direct function calls that often can be inlined by the compiler. Using the rings through an eth_dev API gives you API consistency, but it means that the ring enqueue and dequeue is done via function pointers, which means the calls cannot be inlined directly.) Thanks Richardson, I understand how to use the RIng PMD in above case. Tetsuya Mukawa