From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta01.ornl.gov (mta01.ornl.gov [128.219.177.14]) by dpdk.org (Postfix) with ESMTP id 3E94658C3 for ; Wed, 10 Feb 2016 18:50:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ornl.gov; i=@ornl.gov; q=dns/txt; s=p20151116; t=1455126640; x=1486662640; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=srZ7+ucyO2Zg+DMSutaOmnwyDGhIqQQKiqxT1sf4QeE=; b=BeY3V4B6K4HQjbxC8TvxYR/ZQp1kK8dt1Yr1VxzL6wBAl9pMIttGqWAA i/oamrHh7FnBybkJPPOlQx86/C6Zh0V+u2R5ESnzyRMQDZ6OtWziiU5Aa Hdtyqn5UDAjBA8gd3J2u/QdV9G1V4/5wETCv3X5pBt40D6HuLZKJlyv9P KAZV1W35FTVTpjmpOEYmSptWf+7BYzBxzVtQBgW1T4erIsK06QTk/PnaF F39mX7wlJjoRJ7XqXuFPTIWaazZButfjfg60hAsfpaMH/B1Jw8lwyU6Eq 6TYBR1rH+tUq3zA2kZhPBDbbDvpa8L1akCHyLkQuC/1VwV8F5tgEwmOGp A==; X-SG: RELAYLIST X-IronPort-AV: E=Sophos;i="5.22,426,1449550800"; d="scan'208";a="121533400" Received: from emgwy1.ornl.gov ([160.91.254.9]) by iron1.ornl.gov with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2016 12:50:39 -0500 Received: from [160.91.76.47] (lumos.ornl.gov [160.91.76.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by emgwy1.ornl.gov (Postfix) with ESMTPS id 3q0pXb2XWSz7tMN for ; Wed, 10 Feb 2016 12:50:39 -0500 (EST) To: dev@dpdk.org References: <20160210100154.GB4084@bricha3-MOBL3> From: Lawrence MacIntyre Message-ID: <56BB786E.1090402@ornl.gov> Date: Wed, 10 Feb 2016 12:50:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160210100154.GB4084@bricha3-MOBL3> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Regarding mbuf allocation/free in secondary process 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 17:50:40 -0000 Sara: The use of polling is to provide high throughput. At high bandwidths, interrupt processing is a great contributor to latency and can greatly decrease available bandwidth. Polling eliminates the overhead of interrupts but it will consume an entire CPU. That is why the DPDK library makes it easy to put each thread on a separate core. The downside is that for low bandwidth applications, you end up using a lot of CPU resources spinning in loops waiting for input. Using the techniques Bruce mentioned will allow you to code a low-bandwidth, low CPU utilization app, but it will not be able to handle high bandwidth. You will have to choose one or the other. Unfortunately, computer hardware has a limited number of interrupts that it can handle per second, and those limits make it impractical to handle bandwidths much greater than 1 Gb/s (i.e 10, 40, or 100 Gb/s) using interrupts to handle I/O. Lawrence This one time (02/10/2016 05:01 AM), at band camp, Bruce Richardson wrote: > On Tue, Feb 09, 2016 at 11:43:19PM -0800, Saravana Kumar wrote: >> Hi DPDK community, >> >> >> >> I'd like to have DPDK NIC IO operations in (primary) process and >> execution logic in (secondary) processes. >> Primary process pushes NIC Rx mbufs to Secondary process through S/W ring >> >> Seconary process allocates mbuf for Tx path and pushes down to Primary >> process for NIC Tx >> >> >> I have few doubts here: >> >> 1. If Secondary process dies because of SIGKILL then how can the mbufs >> allocated in Secondary process can be freed. >> If it is normal signals like SIGINT/SIGTERM then we can be catch >> those and free in those respective signal handlers > If a process terminates abnormally then the buffers being used by that process > may well be leaked. The solution you propose of catching signals will certainly > help as you want to try and ensure that a process always frees all its buffers > properly on termination. > >> 2. Secondary process needs to poll on the S/W ring. This can consume 100% cpu. >> Is there a way to avoid polling in secondary process for Rx path > Not using DPDK software rings, no. You'd have to use some kernel constructs such as > fifo's/named pipes to do blocking reads on those. However, the overhead of using > such structures can be severe making them unusable for many packet processing > applications. An alternative might be to use some small sleep calls i.e. nanosleep > between polls of the SW ring in cases where traffic rates are low. That will > reduce your cpu usage. > > /Bruce > > -- Lawrence MacIntyre macintyrelp@ornl.gov Oak Ridge National Laboratory 865.574.7401 Cyber Space and Information Intelligence Research Group