From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Cc: dev@dpdk.org, Olivier Matz <olivier.matz@6wind.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Subject: Re: [PATCH v2] mbuf:rearrange mbuf to be more mbuf chain friendly
Date: Mon, 27 Jun 2016 16:30:38 +0200 [thread overview]
Message-ID: <8530000.4NpoyoCY28@xps13> (raw)
In-Reply-To: <73B00DD6-F266-4A76-8C4E-F875C16D6977@intel.com>
2016-06-27 13:06, Wiles, Keith:
>
> On 6/27/16, 4:05 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
>
> >2016-06-27 10:27, Olivier Matz:
> >> On 06/27/2016 10:21 AM, Ananyev, Konstantin wrote:
> >> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Keith Wiles
> >> >> Move the next pointer to the first cacheline of the rte_mbuf structure
> >> >> and move the offload values to the second cacheline to give better
> >> >> performance to applications using chained mbufs.
> >> >>
> >> >> Enabled by a configuration option CONFIG_RTE_MBUF_CHAIN_FRIENDLY default
> >> >> is set to No.
> >> >
> >> > First, it would make ixgbe and i40e vector RX functions to work incorrectly.
> >> > Second, I don't think we can afford to allow people swap mbuf fields in the way they like.
> >> > Otherwise we'll end-up with totally unmaintainable code pretty soon.
> >> > So NACK.
> >>
> >> +1
> >
> >To be more precise, the arrangement of fields in rte_mbuf is open
> >to debate and changes.
> >There is a recent discussion here:
> > http://dpdk.org/ml/archives/dev/2016-May/039483.html
> >
> >I think we must try to improve few things in mbuf during the 16.11 cycle.
> >But it must not be allowed to have a build option to adapt this structure
> >or any other API. There is only one DPDK API for a given version.
>
> I just received a private email thread on this one and it appears it is not a big of a problem as was stated before. ☹ So yes we can reject this one.
>
> Someone rejected these in patchwork already, which I expected I would be the one to reject the patches. Is this not the case? I understand if the patch just hangs round, but I would have expected after the list rejected the patch I would be the one to reject the patches. I try to keep up with my patches and rejecting a patch before I have a chance to do so seems a bit harsh to me.
Yes it's me, sorry I've been quick when I've seen the first 2 comments.
prev parent reply other threads:[~2016-06-27 14:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-25 15:29 [PATCH] mbuf:rearrange mbuf to be more mbuf chain friendly Keith Wiles
2016-06-25 15:48 ` Wiles, Keith
2016-06-25 15:55 ` [PATCH v2] " Keith Wiles
2016-06-27 8:21 ` Ananyev, Konstantin
2016-06-27 8:27 ` Olivier Matz
2016-06-27 9:05 ` Thomas Monjalon
2016-06-27 13:06 ` Wiles, Keith
2016-06-27 14:30 ` Thomas Monjalon [this message]
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=8530000.4NpoyoCY28@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=keith.wiles@intel.com \
--cc=konstantin.ananyev@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.