Hi Eric,

It looks like the ReleaseData callback would be a good solution for this case, except that ReleaseData is for Packet Data, not Packet Data and Packet Structure.  For mPipe the Suricata Packet structure and Packet data are allocated as one contiguous block of memory, so mPIPE needs a custom function for release packet.

I propose to add a ReleasePacket callback function, which could be:

1)      NULL – For Stack allocated objects

2)      ReleaseAllocPacket() for the PKT_ALLOC flag case

3)      MpipeReleasePacket() for mPIPE allocated packets. In this case, I would leave releaseData NULL.

Since ReleaseData is only used by AF Packet, ReleaeData could be replaced by ReleasePacket() and then modify AFPReleaseDataFromRing() to also free the packet structure.

Regards,
-Ken


From: Eric Leblond [mailto:notifications@github.com]
Sent: Wednesday, June 26, 2013 4:17 AM
To: inliniac/suricata
Cc: Kenneth Steele
Subject: Re: [suricata] Initial Tile mPIPE support (#403)


In src/tmqh-packetpool.c:

> @@ -270,8 +275,15 @@ void TmqhOutputPacketpool(ThreadVars *t, Packet *p)

>              SCFree(p->root);

>              p->root = NULL;

>          } else {

> -            PACKET_RECYCLE(p->root);

> -            RingBufferMrMwPut(ringbuffer, (void *)p->root);

> +#ifdef HAVE_MPIPE

We have the ReleaseData API which is made for that. Take a look at https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Packet_Acquisition_API#Packet-release-mechanism
Basically if p->ReleaseData is a callback function which is called when cleaning the file.
I wonder if it is not possible to get rid of PKT_MPIPE by using this API (or if not we can make it evolve).

—
Reply to this email directly or view it on GitHub<https://github.com/inliniac/suricata/pull/403/files#r4886081>.