From: Neil Horman <nhorman@tuxdriver.com>
To: "Venkatesan, Venky" <venky.venkatesan@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an offset
Date: Mon, 12 May 2014 10:41:08 -0400 [thread overview]
Message-ID: <20140512144108.GB21298@hmsreliant.think-freely.org> (raw)
In-Reply-To: <1FD9B82B8BF2CF418D9A1000154491D9740A92B8@ORSMSX102.amr.corp.intel.com>
On Mon, May 12, 2014 at 02:36:12PM +0000, Venkatesan, Venky wrote:
> Olivier,
>
> This is a hugely problematic change, and has a pretty large performance impact (because the dependency to compute and access). We debated this for a long time during the early days of DPDK and decided against it. This is also a repeated sequence - the driver will do it twice (Rx + Tx) and the next level stack will do it twice (Rx + Tx) ...
>
> My vote is to reject this change particular change to the mbuf.
>
> Regards,
> -Venky
>
Do you have perforamance numbers to compare throughput with and without this
change? I always feel suspcious when I see the spectre of performane used to
support or deny a change without supporting reasoning or metrics.
Neil
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, May 12, 2014 7:13 AM
> To: Olivier Matz
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an offset
>
> Hi Olivier,
>
> 2014-05-09 16:50, Olivier Matz:
> > The mbuf structure already contains a pointer to the beginning of the
> > buffer (m->buf_addr). It is not needed to use 8 bytes again to store
> > another pointer to the beginning of the data.
> >
> > Using a 16 bits unsigned integer is enough as we know that a mbuf is
> > never longer than 64KB. We gain 6 bytes in the structure thanks to
> > this modification.
> >
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> [...]
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -132,6 +132,13 @@ struct rte_mbuf {
> > void *buf_addr; /**< Virtual address of segment buffer. */
> > uint64_t buf_physaddr:48; /**< Physical address of segment buffer. */
> > uint64_t buf_len:16; /**< Length of segment buffer. */
> > +
> > + /* valid for any segment */
> > + struct rte_mbuf *next; /**< Next segment of scattered packet. */
> > + uint16_t data_off;
> > + uint16_t data_len; /**< Amount of data in segment buffer. */
> > + uint32_t pkt_len; /**< Total pkt len: sum of all segments. */
> > +
> > #ifdef RTE_MBUF_REFCNT
> > /**
> > * 16-bit Reference counter.
> > @@ -142,36 +149,30 @@ struct rte_mbuf {
> > * config option.
> > */
> > union {
> > - rte_atomic16_t refcnt_atomic; /**< Atomically accessed refcnt */
> > - uint16_t refcnt; /**< Non-atomically accessed refcnt
> */
> > + rte_atomic16_t refcnt_atomic; /**< Atomically accessed refcnt */
> > + uint16_t refcnt; /**< Non-atomically accessed refcnt */
> > };
> > #else
> > - uint16_t refcnt_reserved; /**< Do not use this field */
> > + uint16_t refcnt_reserved; /**< Do not use this field */
> > #endif
> >
> > - uint16_t ol_flags; /**< Offload features. */
> > - uint32_t reserved; /**< Unused field. Required for padding.
> */
> > -
> > - /* valid for any segment */
> > - struct rte_mbuf *next; /**< Next segment of scattered packet. */
> > - void* data; /**< Start address of data in segment buffer. */
> > - uint16_t data_len; /**< Amount of data in segment buffer. */
> > -
> > /* these fields are valid for first segment only */
> > - uint8_t nb_segs; /**< Number of segments. */
> > - uint8_t in_port; /**< Input port. */
> > - uint32_t pkt_len; /**< Total pkt len: sum of all segment data_len.
> > */ + uint8_t nb_segs; /**< Number of segments. */
> > + uint8_t in_port; /**< Input port. */
> > + uint16_t ol_flags; /**< Offload features. */
> > + uint16_t reserved; /**< Unused field. Required for padding. */
> >
> > /* offload features, valid for first segment only */
> > union rte_vlan_macip vlan_macip;
> > union {
> > - uint32_t rss; /**< RSS hash result if RSS enabled */
> > + uint32_t rss; /**< RSS hash result if RSS enabled */
> > struct {
> > uint16_t hash;
> > uint16_t id;
> > - } fdir; /**< Filter identifier if FDIR enabled */
> > - uint32_t sched; /**< Hierarchical scheduler */
> > - } hash; /**< hash information */
> > + } fdir; /**< Filter identifier if FDIR enabled */
> > + uint32_t sched; /**< Hierarchical scheduler */
> > + } hash; /**< hash information */
> > + uint64_t reserved2; /**< Unused field. Required for padding. */
> > } __rte_cache_aligned;
>
> There are some cosmetic changes mixed with real changes.
> It make hard to read them.
> Please split this patch.
>
> --
> Thomas
>
next prev parent reply other threads:[~2014-05-12 14:41 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 14:50 [dpdk-dev] [PATCH RFC 00/11] ixgbe/mbuf: add TSO support Olivier Matz
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 01/11] igb/ixgbe: fix IP checksum calculation Olivier Matz
2014-05-15 10:40 ` Ananyev, Konstantin
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 02/11] mbuf: rename RTE_MBUF_SCATTER_GATHER into RTE_MBUF_REFCNT Olivier Matz
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 03/11] mbuf: remove rte_ctrlmbuf Olivier Matz
2014-05-25 21:39 ` Gilmore, Walter E
2014-05-26 12:23 ` Olivier MATZ
2014-05-26 16:40 ` Dumitrescu, Cristian
2014-05-26 22:43 ` Neil Horman
2014-05-27 0:17 ` Stephen Hemminger
2014-05-28 9:45 ` Ananyev, Konstantin
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 04/11] mbuf: remove the rte_pktmbuf structure Olivier Matz
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 05/11] mbuf: merge physaddr and buf_len in a bitfield Olivier Matz
2014-05-09 15:39 ` Shaw, Jeffrey B
2014-05-09 16:06 ` Olivier MATZ
2014-05-09 16:11 ` Shaw, Jeffrey B
2014-05-14 14:07 ` Ananyev, Konstantin
2014-05-15 9:53 ` Olivier MATZ
2014-05-19 7:27 ` Olivier MATZ
2014-05-19 8:25 ` Richardson, Bruce
2014-05-19 9:30 ` Olivier MATZ
2014-05-19 9:57 ` Richardson, Bruce
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an offset Olivier Matz
2014-05-12 14:12 ` Thomas Monjalon
2014-05-12 14:36 ` Venkatesan, Venky
2014-05-12 14:41 ` Neil Horman [this message]
2014-05-12 15:07 ` Olivier MATZ
2014-05-12 15:59 ` Stephen Hemminger
2014-05-12 16:13 ` Olivier MATZ
2014-05-12 17:13 ` Stephen Hemminger
2014-05-13 13:29 ` Olivier MATZ
2014-05-12 16:06 ` Venkatesan, Venky
2014-05-12 18:39 ` Neil Horman
2014-05-13 13:54 ` Venkatesan, Venky
2014-05-13 14:09 ` Thomas Monjalon
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 07/11] mbuf: add functions to get the name of an ol_flag Olivier Matz
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 08/11] mbuf: change ol_flags to 32 bits Olivier Matz
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 09/11] mbuf: rename vlan_macip_len in hw_offload and increase its size Olivier Matz
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 10/11] testpmd: modify source address to validate checksum calculation Olivier Matz
2014-05-09 14:50 ` [dpdk-dev] [PATCH RFC 11/11] ixgbe/mbuf: add TSO support Olivier Matz
2014-05-12 14:30 ` Thomas Monjalon
2014-05-15 15:09 ` Ananyev, Konstantin
2014-05-15 15:39 ` Olivier MATZ
2014-05-15 16:30 ` Ananyev, Konstantin
2014-05-16 12:11 ` Olivier MATZ
2014-05-16 17:01 ` Ananyev, Konstantin
2014-05-19 12:32 ` Thomas Monjalon
2014-05-09 17:04 ` [dpdk-dev] [PATCH RFC 00/11] " Stephen Hemminger
2014-05-09 21:49 ` Olivier MATZ
2014-05-10 0:39 ` Stephen Hemminger
2014-05-19 12:47 ` Thomas Monjalon
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=20140512144108.GB21298@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=dev@dpdk.org \
--cc=venky.venkatesan@intel.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).