From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
Olivier Matz <olivier.matz@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH RFC 03/11] mbuf: remove rte_ctrlmbuf
Date: Wed, 28 May 2014 09:45:15 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772580EFB3572@IRSMSX105.ger.corp.intel.com> (raw)
In-Reply-To: <20140526171701.7bd0fadd@nehalam.linuxnetplumber.net>
Hi,
>The only win from this is to save the byte for the type field.
>Yes bits here are precious.
>Does external application mix control and data mbuf's in the same ring?
>The stuff in the tree only uses type field for debug validation/sanity
>checks.
>Since it is only one bit, maybe you can find one bit to store that.
>Since buffer and pool addresses are going to be at least 32 bit aligned
>maybe you can use the old GC trick of using the LSB as flag.
Or, as an alternative we can move mbuf type up into the mempool.
In most cases user has to deal only with one particular type of mbufs and he already knows what mbuf type it would be.
For the rare cases when code need to deal with mix of mbuf types,
it is probably ok to read mbuf type from the corresponding mempool.
Of course, it would mean that all elements in the mempool should have the same type,
but I don't think right now people using mempools with mix of pktmbuf/ctrlmbuf anyway.
Konstantin
next prev parent reply other threads:[~2014-05-28 9:46 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 [this message]
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
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=2601191342CEEE43887BDE71AB9772580EFB3572@IRSMSX105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=olivier.matz@6wind.com \
--cc=stephen@networkplumber.org \
/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).