Thanks for your response.. Sara
On Wed, Feb 10, 2016 at 2:01 AM, Bruce Richardson < bruce.richardson at intel.com> 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 > >
