Thread (8 messages) 8 messages, 5 authors, 2017-12-22

Re: [PATCH v2] doc: announce ABI change for pktmbuf pool create API

From: Neil Horman <nhorman@tuxdriver.com>
Date: 2017-12-18 14:44:19

On Mon, Dec 18, 2017 at 01:51:52PM +0000, Wiles, Keith wrote:
quoted
On Dec 15, 2017, at 4:41 AM, Hemant Agrawal [off-list ref] wrote:

Introduce a new argument ops_name in rte_mempool_set_ops_byname
for allowing the application to optionally specify the mempool ops.

Signed-off-by: Hemant Agrawal <redacted>
---
v2: fix checkpatch error

doc/guides/rel_notes/deprecation.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 13e8543..968ca14 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -53,3 +53,6 @@ Deprecation Notices
* librte_meter: The API will change to accommodate configuration profiles.
  Most of the API functions will have an additional opaque parameter.
+
+* librte_mbuf: a new optional parameter for representing name of mempool_ops
+  will be added to the API ``rte_pktmbuf_pool_create``.

Sorry, for the late response I was on vacation.

My question is why do we need to change rte_pktmbuf_pool_create ABI yet again, why could we not add a new API to just set the name of the pool after it is created. This would allow all current applications to work without any ABI breakage and only require adding a new API call for anyone that wants the name. The rte_pktmbuf_pool_create() routine could assign a default name or some incrementing style name as the default. e.g. ‘pktmbuf_%d’ with a static incrementing variable or whatever you like.

Sorry if this was asked and answered before.
+1, that seems like the more flexible solution.
Neil
quoted
-- 
2.7.4
Regards,
Keith
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help