From: "Richardson, Bruce" <bruce.richardson@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 01/14] mbuf: rename RTE_MBUF_SCATTER_GATHER into RTE_MBUF_REFCNT
Date: Tue, 12 Aug 2014 16:25:18 +0000 [thread overview]
Message-ID: <59AF69C657FD0841A61C55336867B5B0343D8C21@IRSMSX103.ger.corp.intel.com> (raw)
In-Reply-To: <53E9C96F.6050904@6wind.com>
Ok, thanks, I'll see about fixing those.
I see a number of comments about the format and structure of the patch set itself. I'll take those all on board, but I'll admit that I didn't rework the patchset much before submitting it as an RFC. I'm leaving that until I've finished on this and ready to start submitting non-RFC patchset for merge. Right now my primary concern is whether the reworked struct rte_mbuf has everything we need, and whether there are any performance regressions we need to fix due to the second cache line.
Regards,
/Bruce
> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Tuesday, August 12, 2014 1:00 AM
> To: Richardson, Bruce
> Cc: Stephen Hemminger; dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH 01/14] mbuf: rename
> RTE_MBUF_SCATTER_GATHER into RTE_MBUF_REFCNT
>
> Hi Bruce,
>
> On 08/11/2014 11:45 PM, Stephen Hemminger wrote:
> > On Mon, 11 Aug 2014 21:44:37 +0100
> > Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> >> From: Olivier Matz <olivier.matz@6wind.com>
> >>
> >> It seems that RTE_MBUF_SCATTER_GATHER is not the proper name for the
> >> feature it provides. "Scatter gather" means that data is stored using
> >> several buffers. RTE_MBUF_REFCNT seems to be a better name for that
> >> feature as it provides a reference counter for mbufs.
> >>
> >> The macro RTE_MBUF_SCATTER_GATHER is poisoned to ensure this
> >> modification is seen by drivers or applications using it.
> >>
> >> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> >> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>
> After applying this first patch, I still get references to
> "scatter gather":
>
> $ git grep RTE_MBUF_SCATTER_GATHER
> examples/Makefile:DIRS-$(CONFIG_RTE_MBUF_SCATTER_GATHER) +=
> ip_fragmentation
> examples/Makefile:DIRS-$(CONFIG_RTE_MBUF_SCATTER_GATHER) +=
> ipv4_multicast
> examples/ip_fragmentation/Makefile:ifneq
> ($(CONFIG_RTE_MBUF_SCATTER_GATHER),y)
> examples/ip_fragmentation/Makefile:$(error This application requires
> RTE_MBUF_SCATTER_GATHER to be enabled)
> examples/ip_pipeline/Makefile:ifeq
> ($(CONFIG_RTE_MBUF_SCATTER_GATHER),y)
> lib/librte_mbuf/rte_mbuf.h:#pragma GCC poison RTE_MBUF_SCATTER_GATHER
> lib/librte_port/Makefile:ifeq ($(CONFIG_RTE_MBUF_SCATTER_GATHER),y)
> lib/librte_port/Makefile:ifeq ($(CONFIG_RTE_MBUF_SCATTER_GATHER),y)
>
> Olivier
next prev parent reply other threads:[~2014-08-12 16:22 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 20:44 [dpdk-dev] [RFC PATCH 00/14] Extend the mbuf structure Bruce Richardson
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 01/14] mbuf: rename RTE_MBUF_SCATTER_GATHER into RTE_MBUF_REFCNT Bruce Richardson
2014-08-11 21:45 ` Stephen Hemminger
2014-08-12 7:59 ` Olivier MATZ
2014-08-12 16:25 ` Richardson, Bruce [this message]
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 02/14] mbuf: remove rte_ctrlmbuf Bruce Richardson
2014-08-12 8:27 ` Olivier MATZ
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 03/14] mbuf: remove the rte_pktmbuf structure Bruce Richardson
2014-08-12 8:38 ` Olivier MATZ
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 04/14] mbuf: replace data pointer by an offset Bruce Richardson
2014-08-12 8:55 ` Olivier MATZ
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 05/14] mbuf: rename in_port to just port Bruce Richardson
2014-08-12 9:00 ` Olivier MATZ
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 06/14] mbuf: reorder fields by time-of-use Bruce Richardson
2014-08-12 10:03 ` Olivier MATZ
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 07/14] ixgbe: rework vector pmd following mbuf changes Bruce Richardson
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 08/14] mbuf: split mbuf across two cache lines Bruce Richardson
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 09/14] Fix performance regression due to moved pool ptr Bruce Richardson
2014-08-12 11:28 ` Olivier MATZ
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 10/14] mbuf: set next pointer to NULL on mbuf free Bruce Richardson
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 11/14] ixgbe: make mbuf_initializer queue variable global Bruce Richardson
2014-08-11 21:47 ` Stephen Hemminger
2014-08-11 22:03 ` Richardson, Bruce
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 12/14] ixgbe: Make vector stores unaligned Bruce Richardson
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 13/14] mbuf: cleanup + added in additional mbuf fields Bruce Richardson
2014-08-12 14:18 ` Olivier MATZ
2014-08-11 20:44 ` [dpdk-dev] [RFC PATCH 14/14] ixgbe: Allow vector RX of scattered packets Bruce Richardson
2014-08-12 14:43 ` [dpdk-dev] [RFC PATCH 00/14] Extend the mbuf structure Olivier MATZ
2014-08-20 12:22 ` Richardson, Bruce
2014-08-20 7:08 ` Cao, Min
2014-08-20 11:11 ` Richardson, Bruce
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=59AF69C657FD0841A61C55336867B5B0343D8C21@IRSMSX103.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--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).