From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 573D12E83 for ; Wed, 10 Feb 2016 11:01:58 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP; 10 Feb 2016 02:01:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,425,1449561600"; d="scan'208";a="45487224" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.159]) by fmsmga004.fm.intel.com with SMTP; 10 Feb 2016 02:01:55 -0800 Received: by (sSMTP sendmail emulation); Wed, 10 Feb 2016 10:01:54 +0025 Date: Wed, 10 Feb 2016 10:01:54 +0000 From: Bruce Richardson To: Saravana Kumar Message-ID: <20160210100154.GB4084@bricha3-MOBL3> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org 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 10:01:58 -0000 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