[Ntop-misc] PF_RING, Zero copy and freeing packets

[Luca Deri]

Hi James

On Apr 12, 2012, at 12:49 PM, James Hunter wrote:

> Thanks for the quick reply, I`ll definitely have to check out libzero when I get myself accustomed to PF_RING.
> 
> I've a similar question with transmitting packets:
> 
> When I transmit on a previously (zero copy) received packet the memory is "freed" or returned to the pool, however If I'm generating my own packets (using malloc) how is the freeing of this memory handled?

Have a look at pfsend. If you use DNA, you can ask PF_RING to give you the memory slots from the NIC so that you can memcpy() your packets. As this might not be practical for your system (we are aware that in most cases this technique can't be used), all you have to do is to pass a buffer to pfring_send(). When the API call returns your are free to reuse your memory, as pfring_send() has copied the packet payload onto the TX slot. So basically there is no memory management involved.

With libzero you will have the possibility of telling the system to give you some memory where you will prepare your packets, and then when you decide it's time to send the packet out, the libzero will swap the memory you have used with a new memory area that will be returned you. Basically you do not have to wait until the packet is transmitted, and also have a buffer back for later usage where you can store your next packet.

The trick is to avoid memory management, so we have created an API that prevents you from doing memory allocation/free per packet. THis is the reason why for instance on a 1.86 GHz Core2Duo we can transmit over 14.2 Mpps, thing that is practically impossible on Linux due to memory management of skbuf's

Cheer Luca


> 
> I can see two options, firstly pfring_send() free's the memory for me (either immediately or when its sent on the wire) or I can free the memory immediately after the pfring_send() function.
> 
> Regards,
> 
> James
>> James
>> with the "classic" (non-DNA) PF_RING the packet is valid until you move to the next one. This for RX and TX. So if you need to keep it you must copy it.
>> 
>> In DNA it's the same, but we're almost down with a new library called libzero that (it's not just limited to this) allows you to
>> 1. keep packets in memory for later processing without copy (e.g. you need to collect all fragments and then process them at that point)
>> 2. enlarge the buffer beyond the physical card memory size
>> 3. switch/transmit/modify packets in zero-copy (as you can see we have published some results on http://www.ntop.org/pf_ring/pf_ring-dna-rfc-2544-benchmark/) across interfaces with minimal latency typical of switches
>> 
>> Libzero will be made available later this month, but in the meantime you can start testing it using the code that's currently in SVN
>> 
>> REgards Luca
>> 
>> On Apr 12, 2012, at 10:32 AM, James Hunter wrote:
>> 
>>> Hi,
>>> 
>>> I'm trying to understand the ownership of packet memory in PF_RING.
>>> 
>>> I don't see any explicit way of telling PF_RING to "free" or release the packet when I'm finished with it, does the packet memory remain valid until a) you call recv again, b) recv returns a new packet or c) you transmit the packet on?
>>> 
>>> What if I don't want to transmit the packet on, or receive another packet?
>>> 
>>> Regards,
>>> 
>>> James
>>> _______________________________________________
>>> Ntop-misc mailing list
>>> Ntop-misc at listgateway.unipi.it
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc at listgateway.unipi.it
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>> 
> 
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc at listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc