Re: [PATCH v6 08/13] pcapng: split packet copy from header insertion

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 23 Jul 2025 06:32:45 +0400 (+04)
Ivan Malov <ivan.malov@arknetworks.am> wrote:

> Hi Stephen,
> 
> On Tue, 22 Jul 2025, Stephen Hemminger wrote:
> 
> > In new model, the packet was already copied, only need  
> 
> Copied? But what if it was "indirect attached" instead, as the model envisages?
> 
> Perhaps this is a silly question of mine, but it may not be clear what happens
> in case of 'RTE_ETH_MIRROR_INDIRECT_FLAG' - whether it is safe to modify the
> mbuf and whether the 'indirect' clone has to be "freed" in the sense of being
> detached/refcnt updated after successful pcapng write, to avoid memory leaks?

The indirect attached is for the direct (no pcap case). Code should
have checked for flag conflict.

I dropped the flag in next version, too may possible bugs and not useful
for the case of packet capture. The problem is that indirect method assumes
that transmit can handle reference counts (won't work with fast free), and
on receive that upper layers do not overwrite packet with refcount > 1.
The Linux and BSD kernel stack have these semantics, but DPDK does not
make the requirement explicit. I.e too many risks for something that
is experimental without current users.