Memorymanagement vs thread safety

Memorymanagement vs thread safety

[Szokovacs Robert]

[-- Attachment #1.1: Type: text/plain, Size: 1335 bytes --]

Hello,


In may application, I use separate threads to process the packets
received (write them to disk or respond to them). I could not confirm to
myself that is is safe to free (using rte_pktmbuf_free
) the memory returned by rte_eth_rx_burst() from a different thread than
the one it was called in.Anybody can help me with this?


Thank you!

br

Szo

Robert Szokovacs
Software Developer

Tel: 0333 240 3276
Email: Robert.Szokovacs@gamma.co.uk


This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at The Scalpel, 18th Floor, 52 Lime Street, London EC3M 7AF and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.

[-- Attachment #1.2: Type: text/html, Size: 9014 bytes --]

[-- Attachment #2: image819850.jpg --]
[-- Type: image/jpeg, Size: 60772 bytes --]

[-- Attachment #3: image808551.jpg --]
[-- Type: image/jpeg, Size: 14534 bytes --]

[-- Attachment #4: image447703.jpg --]
[-- Type: image/jpeg, Size: 91601 bytes --]

[-- Attachment #5: image505921.png --]
[-- Type: image/png, Size: 18443 bytes --]

Re: Memorymanagement vs thread safety

[Tao Li]

[-- Attachment #1.1: Type: text/plain, Size: 2187 bytes --]

Hi,

In general it is not wrong to directly free mbufs from another thread assuming it is not freed twice in both threads. But a safer way for your purpose is to create shared ring buffer between these two threads. You can pass pointers of obtained mbufs from the receiving thread to the processing thread, then get the processing status back also via the ring buffer and safely free them in the same receiving thread.

Cheers,
Tao

From: Szokovacs Robert <robert.szokovacs@gamma.co.uk>
Date: Monday, 8. April 2024 at 15:25
To: users@dpdk.org <users@dpdk.org>
Subject: Memorymanagement vs thread safety

Hello,



In may application, I use separate threads to process the packets received (write them to disk or respond to them). I could not confirm to myself that is is safe to free (using rte_pktmbuf_free
) the memory returned by rte_eth_rx_burst() from a different thread than the one it was called in. Anybody can help me with this?



Thank you!

br

Szo
Robert Szokovacs
Software Developer
Tel:
0333 240 3276<tel:0333%20240%203276>
Email:
Robert.Szokovacs@gamma.co.uk<mailto:Robert.Szokovacs@gamma.co.uk>
[cid:image819850.jpg@7A800801.FE27EB93]
[cid:image808551.jpg@887325EE.BD0939A7]

[cid:image447703.jpg@A6076DF8.C9CBF213]
[cid:image505921.png@28AF8B20.6BF58847]
This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster@gamma.co.uk​​​​

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at The Scalpel, 18th Floor, 52 Lime Street, London EC3M 7AF and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


[-- Attachment #1.2: Type: text/html, Size: 13067 bytes --]

[-- Attachment #2: image819850.jpg --]
[-- Type: image/jpeg, Size: 60772 bytes --]

[-- Attachment #3: image808551.jpg --]
[-- Type: image/jpeg, Size: 14534 bytes --]

[-- Attachment #4: image447703.jpg --]
[-- Type: image/jpeg, Size: 91601 bytes --]

[-- Attachment #5: image505921.png --]
[-- Type: image/png, Size: 18443 bytes --]