Re: multi-process support: how to share THE SAME packet between two different processes

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 28 Nov 2022 15:10:39 +0100
ikuzar RABE <ikuzar9295@gmail.com> wrote:

> In this case:  9. DPDK packet capture libraries and tools — Data Plane
> Development Kit 22.11.0 documentation
> <https://doc.dpdk.org/guides/howto/packet_capture_framework.html>, which
> process is responsible of deallocing the memory occupied by a packet ? the
> primary process or the dpdk-dumpcap tool process ?
> if one process deallocates a memory, the second one will point to nothing...
> 
> ikuzar
> 
> i
> 
> Le ven. 25 nov. 2022 à 18:09, Stephen Hemminger <stephen@networkplumber.org>
> a écrit :
> 
> > On Fri, 25 Nov 2022 17:27:46 +0100
> > ikuzar RABE <ikuzar9295@gmail.com> wrote:
> >  
> > > Hi all,
> > >
> > > I would like to know how do you usually proceed to retrieve and share the
> > > same packet read from NIC port between two different processes ? I try to
> > > work in zero-copy way.
> > >
> > > The first process job consists in parsing the packet and make some  
> > protocol  
> > > statistics. The second one dumps the same packet into pcap file for  
> > further  
> > > analysis with wireshark for example.
> > >
> > > I think none of the cases exposed here corresponds to my need: 43.
> > > Multi-process Support — Data Plane Development Kit 22.11.0-rc4
> > > documentation (dpdk.org)
> > > <  
> > https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html#:~:text=Standalone%20DPDK%20processes%20are%20primary,process%20with%20same%20DPDK%20version  
> > .>.
> > > Am I wrong ?
> > >
> > > is there a dpdk-compliant way to do it with threads instead of processes  
> > ?  
> > >
> > > Thank you for your help.
> > >
> > > Regards,
> > >
> > > ikuzar  
> >
> > Use a ring buffer.
> > Why are you reinventing what the pdump library does?
> >  

Please do not top quote on mailing lists.

The DPDK uses the concept of packet ownership (like BSD and Linux kernels).
The mbuf is allocated by the receiving poll mode driver and returned by the rx_burst call.
At that point ownership is in the application.
The application may:

   - free the mbuf immediately
   - pass it to a driver transmit; this passes ownership to the PMD
   - enqueue it in a ring or other mechanism; this passes ownership to the ring reader

The owner, which is a thread in primary or secondary can free the mbuf.
It gets a little more complicated if reference counts are used. In that case:
   - when reference count is decremented to zero, the mbuf is freed
   - if reference count is greater than one, then the mbuf should be treated as read-only.

Most code gets the last thing wrong.