From: Hemant Agrawal <hemant.agrawal@nxp.com>
To: Olivier Matz <olivier.matz@6wind.com>, <dev@dpdk.org>
Cc: <jerin.jacob@caviumnetworks.com>, <david.hunt@intel.com>
Subject: Re: [dpdk-dev] [RFC 0/7] changing mbuf pool handler
Date: Thu, 22 Sep 2016 17:22:45 +0530 [thread overview]
Message-ID: <d11f3842-d715-3afc-9d5d-9e02f2767c2d@nxp.com> (raw)
In-Reply-To: <1474292567-21912-1-git-send-email-olivier.matz@6wind.com>
Hi Olivier
On 9/19/2016 7:12 PM, Olivier Matz wrote:
> Hello,
>
> Following discussion from [1] ("usages issue with external mempool").
>
> This is a tentative to make the mempool_ops feature introduced
> by David Hunt [2] more widely used by applications.
>
> It applies on top of a minor fix in mbuf lib [3].
>
> To sumarize the needs (please comment if I did not got it properly):
>
> - new hw-assisted mempool handlers will soon be introduced
> - to make use of it, the new mempool API [4] (rte_mempool_create_empty,
> rte_mempool_populate, ...) has to be used
> - the legacy mempool API (rte_mempool_create) does not allow to change
> the mempool ops. The default is "ring_<s|m>p_<s|m>c" depending on
> flags.
> - the mbuf helper (rte_pktmbuf_pool_create) does not allow to change
> them either, and the default is RTE_MBUF_DEFAULT_MEMPOOL_OPS
> ("ring_mp_mc")
> - today, most (if not all) applications and examples use either
> rte_pktmbuf_pool_create or rte_mempool_create to create the mbuf
> pool, making it difficult to take advantage of this feature with
> existing apps.
>
> My initial idea was to deprecate both rte_pktmbuf_pool_create() and
> rte_mempool_create(), forcing the applications to use the new API, which
> is more flexible. But after digging a bit, it appeared that
> rte_mempool_create() is widely used, and not only for mbufs. Deprecating
> it would have a big impact on applications, and replacing it with the
> new API would be overkill in many use-cases.
I agree with the proposal.
>
> So I finally tried the following approach (inspired from a suggestion
> Jerin [5]):
>
> - add a new mempool_ops parameter to rte_pktmbuf_pool_create(). This
> unfortunatelly breaks the API, but I implemented an ABI compat layer.
> If the patch is accepted, we could discuss how to announce/schedule
> the API change.
> - update the applications and documentation to prefer
> rte_pktmbuf_pool_create() as much as possible
> - update most used examples (testpmd, l2fwd, l3fwd) to add a new command
> line argument to select the mempool handler
>
> I hope the external applications would then switch to
> rte_pktmbuf_pool_create(), since it supports most of the use-cases (even
> priv_size != 0, since we can call rte_mempool_obj_iter() after) .
>
I will still prefer if you can add the "rte_mempool_obj_cb_t *obj_cb,
void *obj_cb_arg" into "rte_pktmbuf_pool_create". This single
consolidated wrapper will almost make it certain that applications will
not try to use rte_mempool_create for packet buffers.
> Comments are of course welcome. Note: the patchset is not really
> tested yet.
>
>
> Thanks,
> Olivier
>
> [1] http://dpdk.org/ml/archives/dev/2016-July/044734.html
> [2] http://dpdk.org/ml/archives/dev/2016-June/042423.html
> [3] http://www.dpdk.org/dev/patchwork/patch/15923/
> [4] http://dpdk.org/ml/archives/dev/2016-May/039229.html
> [5] http://dpdk.org/ml/archives/dev/2016-July/044779.html
>
>
> Olivier Matz (7):
> mbuf: set the handler at mbuf pool creation
> mbuf: use helper to create the pool
> testpmd: new parameter to set mbuf pool ops
> l3fwd: rework long options parsing
> l3fwd: new parameter to set mbuf pool ops
> l2fwd: rework long options parsing
> l2fwd: new parameter to set mbuf pool ops
>
> app/pdump/main.c | 2 +-
> app/test-pipeline/init.c | 3 +-
> app/test-pmd/parameters.c | 5 +
> app/test-pmd/testpmd.c | 16 +-
> app/test-pmd/testpmd.h | 1 +
> app/test/test_cryptodev.c | 2 +-
> app/test/test_cryptodev_perf.c | 2 +-
> app/test/test_distributor.c | 2 +-
> app/test/test_distributor_perf.c | 2 +-
> app/test/test_kni.c | 2 +-
> app/test/test_link_bonding.c | 2 +-
> app/test/test_link_bonding_mode4.c | 2 +-
> app/test/test_link_bonding_rssconf.c | 11 +-
> app/test/test_mbuf.c | 6 +-
> app/test/test_pmd_perf.c | 3 +-
> app/test/test_pmd_ring.c | 2 +-
> app/test/test_reorder.c | 2 +-
> app/test/test_sched.c | 2 +-
> app/test/test_table.c | 2 +-
> doc/guides/prog_guide/mbuf_lib.rst | 2 +-
> doc/guides/sample_app_ug/ip_reassembly.rst | 13 +-
> doc/guides/sample_app_ug/ipv4_multicast.rst | 12 +-
> doc/guides/sample_app_ug/l2_forward_job_stats.rst | 33 ++--
> .../sample_app_ug/l2_forward_real_virtual.rst | 26 ++-
> doc/guides/sample_app_ug/ptpclient.rst | 12 +-
> doc/guides/sample_app_ug/quota_watermark.rst | 26 ++-
> drivers/net/bonding/rte_eth_bond_8023ad.c | 13 +-
> drivers/net/bonding/rte_eth_bond_alb.c | 2 +-
> examples/bond/main.c | 2 +-
> examples/distributor/main.c | 2 +-
> examples/dpdk_qat/main.c | 3 +-
> examples/ethtool/ethtool-app/main.c | 4 +-
> examples/exception_path/main.c | 3 +-
> examples/ip_fragmentation/main.c | 4 +-
> examples/ip_pipeline/init.c | 19 ++-
> examples/ip_reassembly/main.c | 16 +-
> examples/ipsec-secgw/ipsec-secgw.c | 2 +-
> examples/ipv4_multicast/main.c | 6 +-
> examples/kni/main.c | 2 +-
> examples/l2fwd-cat/l2fwd-cat.c | 3 +-
> examples/l2fwd-crypto/main.c | 2 +-
> examples/l2fwd-jobstats/main.c | 2 +-
> examples/l2fwd-keepalive/main.c | 2 +-
> examples/l2fwd/main.c | 36 ++++-
> examples/l3fwd-acl/main.c | 2 +-
> examples/l3fwd-power/main.c | 2 +-
> examples/l3fwd-vf/main.c | 2 +-
> examples/l3fwd/main.c | 180 +++++++++++----------
> examples/link_status_interrupt/main.c | 2 +-
> examples/load_balancer/init.c | 2 +-
> .../client_server_mp/mp_server/init.c | 3 +-
> examples/multi_process/l2fwd_fork/main.c | 14 +-
> examples/multi_process/symmetric_mp/main.c | 2 +-
> examples/netmap_compat/bridge/bridge.c | 2 +-
> examples/packet_ordering/main.c | 2 +-
> examples/performance-thread/l3fwd-thread/main.c | 2 +-
> examples/ptpclient/ptpclient.c | 3 +-
> examples/qos_meter/main.c | 2 +-
> examples/qos_sched/init.c | 2 +-
> examples/quota_watermark/qw/main.c | 2 +-
> examples/rxtx_callbacks/main.c | 2 +-
> examples/skeleton/basicfwd.c | 3 +-
> examples/tep_termination/main.c | 17 +-
> examples/vhost/main.c | 2 +-
> examples/vhost_xen/main.c | 2 +-
> examples/vmdq/main.c | 2 +-
> examples/vmdq_dcb/main.c | 2 +-
> lib/librte_mbuf/rte_mbuf.c | 34 +++-
> lib/librte_mbuf/rte_mbuf.h | 44 +++--
> lib/librte_mbuf/rte_mbuf_version.map | 7 +
> 70 files changed, 366 insertions(+), 289 deletions(-)
>
next prev parent reply other threads:[~2016-09-22 11:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 13:42 Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 1/7] mbuf: set the handler at mbuf pool creation Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 2/7] mbuf: use helper to create the pool Olivier Matz
2017-01-16 15:30 ` Santosh Shukla
2017-01-31 10:31 ` Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 3/7] testpmd: new parameter to set mbuf pool ops Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 4/7] l3fwd: rework long options parsing Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 5/7] l3fwd: new parameter to set mbuf pool ops Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 6/7] l2fwd: rework long options parsing Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 7/7] l2fwd: new parameter to set mbuf pool ops Olivier Matz
2016-09-22 11:52 ` Hemant Agrawal [this message]
2016-10-03 15:49 ` [dpdk-dev] [RFC 0/7] changing mbuf pool handler Olivier Matz
2016-10-05 9:41 ` Hunt, David
2016-10-05 11:49 ` Hemant Agrawal
2016-10-05 13:15 ` Hunt, David
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d11f3842-d715-3afc-9d5d-9e02f2767c2d@nxp.com \
--to=hemant.agrawal@nxp.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=olivier.matz@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).