DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier MATZ <olivier.matz@6wind.com>
To: Bruce Richardson <bruce.richardson@intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC PATCH 13/14] mbuf: cleanup + added in additional mbuf fields.
Date: Tue, 12 Aug 2014 16:18:31 +0200	[thread overview]
Message-ID: <53EA2237.50502@6wind.com> (raw)
In-Reply-To: <1407789890-17355-14-git-send-email-bruce.richardson@intel.com>

Hi Bruce,

On 08/11/2014 10:44 PM, Bruce Richardson wrote:
> Cleanups:
> * use typedefs for markers within mbuf struct
> * split up vlan_macip field as the l2/l3 lengths are for TX so go on the
>    second cache line.
> * created a tx_ol field in second cache line for data used for tx
>    offloads
> * rename the hash field to the filter field as it contains more than
>    just a hash value.
>
> Added in the extra mbuf fields needed:
> * fdir flex bytes for i40e driver, i.e. extra 32-bits for filters
> * field to be used for a sequence number, extra 32-bit field
> * field for a second vlan tag, extra 16-bits, using space freed by
>    moving out the l2 l3 lengths.
> * userdata field for general application use.
> * added inner_l3 and l4 length fields to allow tunneling.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

I think it would be clearer if splitted in several patches. First
2 patches for:

- rename hash in filter
- rename vlan_macip in rte_tx_offloads (and change to 64 bits ?)

By the way, the modification of ol_flags in 64 bits probably
requires more modifications in driver and testpmd. See me initial
patch "mbuf: change ol_flags to 32 bits".

Why not directly adding the MARKER typedef in previous patches?
Also, I'm wondering if the markers really need to by typed. An empty
struct would do the job, just requiring the users to cast it into
the proper type.

About sequence, double vlan id, userdata: they are not used now.
I think we should add them one by one in separate patches, with
code really that really requires the added field to be present.
By the way, there is already a way to reserve a zone in mbuf for
the application at mbuf pool creation. What is the purpose of
the userdata field?

About fdir_i40e field, I'm not sure that we should have
driver-specific info in the generic mbuf structure. In addition,
the application would need to know which hash type is present
in the mbuf.

Each time we add a new field in the mbuf, I think we should ask
ourselves how the application will use it, especially if the
application manages several kind of ports (virtual and
physical for instance), which may not support all features.
For instance, who will fill the "sequence" field ? Is it the
driver? If it's application-specific

Regards,
Olivier

  reply	other threads:[~2014-08-12 14:15 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
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 [this message]
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=53EA2237.50502@6wind.com \
    --to=olivier.matz@6wind.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.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).